Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.
Richard Wackerbarth writes: However, we need to keep the level of integration issue open until someone (presumedly the student) completes an inventory of reasonable possibilities. I would like to leave that up to Peter. (We should avoid burdening the students with chores like inventorying possibilities, unless it helps them decide requirements, design the application, and code the implementation.) BTW http://tools.ietf.org/html/rfc6068 describes the mailto: URI. It's remarkably flexible, although the body does present some special problems. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Project Discussion
Richard Wackerbarth writes: Would it be easier if we just treated owners and moderators as a couple of additional mailing lists. That would require additional, complex attributes that aren't appropriate for most lists to be given to all lists. They'd have to have a .virtual_list_for attribute, for example. If non-null, you can't post to it. (Or can you? Messy.) The owner list would have to have a .cant_delete_last_subscriber attribute. These lists need to be suppressed when working with the set of real mailing lists. These lists should be exempted from spam-checking since only Mailman core ever posts to them. (Or should they? See above.) I think this all violates duck-typing and gets messier, not easier. Thus a moderator would be subscribed to the XXX(moderators) list and that subscription handled just as any other subscription would be handled. I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators. My $0.02. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Project Discussion
Richard Wackerbarth writes: I agree that it might be messier. But it still might be cleaner if you want the moderators, etc. to have all of the subscription options We don't. Some are meaningless (notMeToo, noDups), some should not be available (noMail -- at least not if a vacation facility is available). I don't contest that there are strong similarities between a list of moderators and a mailing list of subscribers. What I'm saying is that they're not the same, there are several variations on the theme, and we must strongly consider deriving them from a more general type. I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators. That all depends on how you present it, not on how you implement it. IIRC, the list of moderators is a roster, just like the subscribers. A different template can make two rosters appear to be quite different. The developers are users too, though. I think the implementation, not just the presentation, should correspond to our notions of what things are. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Project Discussion
varun sharma writes: 1. The mail delivery will be stopped for moderators as well as list owners. So the moderators should also not receive any add request pending email during the vacation period. Moderators and owners need to have their vacations treated differently from other users, especially for mail forwarded from the -owner alias. (Hi, this is your friendly ISP. You have 24 hours to fix the backscatter or we will consider you in breach of our AUP and terminate your account.) One possibility would be to switch notifications to batch (once a day, once every couple of days) and send them as a digest rather than individually. This might also be a good possibility for users (but the relevant batching period might be longer). ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]
Daniel Kahn Gillmor writes: Is implementing this option something that would be part of the first phase of the work, or should it be part of a later phase? He can implement it whenever he wants :-), but if I were his GSoC mentor, he'd be getting paid for something else (ie, the pure authentication part). Barry and Wacky think similarly I believe. Maybe the mailman devs can answer this question: does mailman already do something like this to check against message-ids that have already been delivered to prevent duplicate delivery? I don't recall for sure but I don't think so. I tend to think it's too much effort. We do worry about routing cycles and handle that with X-Been-Seen fields. Message-IDs themselves are not very useful; in my own experience repeated message IDs are invariably due to Post-and-Mail issues (which we deal with post-by-post by checking the NoDupes flag on any addressees who appear in the list). Duplicate originals tend to be due to keyboard bounce (ie, for some reason the user resends within a number of seconds) or moderation delays -- in both cases usually they end up with different Message-IDs. Thanks, I really appreciate your engagement with these questions. There are a lot of finicky details to keep track of, and you're coming up to speed fast on questions that most people haven't thought about at all. Keep it up! +1 ! Also, Abhilash, I believe it would be very helpful to you later to blog about these conversations now.[1] Your blog entries should not be fire-and-forget; you should have separate entries for different topics and go back and update entries as you learn more. It might also be helpful to keep links to the mm-dev archive posts as references in your blog. (I haven't actually practiced that last myself, but it seems plausible.) It *will* seem like too much effort at first, but (1) people forget things unbelievably fast, and (2) you'll get better at it quickly. STeve Footnotes: [1] Maybe you already have, if so, my apologies. I'll go check later. :-) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]
Abhilash Raj writes: This part is little difficult to ponder on. Suppose a user signs up for a list. He creates a user account and subscribes to a particular list which needs his pub-key and implements signing. In Mailman 3, users and subscriptions are separate concepts. We should assume that users and subscriptions are both authenticated, potentially separately. I think that to start with, we can assume that the user key will be used for all user configuration (subscription, etc), and for posting. The second stage would be to allow a list to require a separate key (subkey) for posting. The third stage would be to require a separate key for administration (user configuration). If he signs up for a single list which does not require signing then what? There will not be any key to sign administrative requests. For starters we'll simply require a separate installation for secure and insecure lists. The whole Mailman instance is secure and all users must have user keys. This is a proof-of-concept implementation; we think about weaker and more complex security models later. sure, but the From: header is forgeable, right? so if Alice knows that Bob was subscribed to list X in the past, and is subscribed to list Y today, then she could dig up his old posts in list X, and forward them (From: header intact!) directly to list Y. Should list Y publish them? Sure, but a secure list should be on a site using DKIM and this will fail the DKIM check, I think. Alternatively you can set up the list so that the whole post (originator headers included) is sent as an attachment (a signed part of a multipart message). The list can then prepend the trace headers (informational only, not authenticable) from the wrapper message when it forwards the encapsulated message. Outlook users will generally not be able to do this, so it's another proof of concept. :-) This is like a secure tunnel (eg, using SSH port forwarding). No, I think if someone tries to send any of his previous message again we can rebound it saying that the same message was posted before. Sure, but identifying that requires secure headers. See above. Also the time-stamp from the message signature would indicate that the message was indeed signed long time back and hence should be bounced back without checking if it was a replay of an old message. Here a 'long time' may be a cutoff set by the list owner which may default to one week considering the delay in smtp delivery( which you mentioned to be 4 days at maximum). SMTP doesn't really work that way; there are no time guarantees (the chain of forward can be arbitrarily long, and each one will retry for up to 4 days in normal configurations). Furthermore, I regularly see spew from Windows boxes with mail written offline. I think the *principle* of using the signature's time-stamp is OK, but the cutoff time should be determined by the list's sense of how long post content can stay hot. A cutoff of one week should be sufficient to include the small time( at max a day ) I've seen many cases where timestamp skew on authentic messages was much greater than a day. Again, this is a matter for list policy. Is the timestamp in the OpenPGP signature not forgeable? Does it not depend on the hardware clock of the system where the message was signed? It's forgeable, but only by the owner of the private key. The hardware clock could be deliberately skewed, but I can't see how that would create a useful attack on a list. (I guess you could imagine a scenario with a deadman switch controlling a message that would be sent if the creator doesn't cancel it, but that's a scenario for Mission Impossible IV, I think.) (if means is earlier than: X Y Z) X: message signature created (according to OpenPGP timestamp) Y: key expired Z: message received by mailman I don't understand the point of this scenario. X is a valid signature, and there are known to be delays in delivery. X should just be treated as an old signature. yep, mailman generates messages of this form from PGP/MIME-signed messages. That said, mailman's generated messages aren't usually sent to mailman as input; maybe mailman shouldn't process these as signed messages? Such messages can be generated in many ways; the fact that Mailman does is just a proof of concept. What is the structure of message with quoted text( when replying to a mail inline )? It's a flat body. It has no MIME structure unless the user deliberately creates it (well, in some cases attachments may be automatically forwarded). Are those signed by the user replying to it? The interesting question is whether the quote is signed by the OP, and the answer it that no, it can't be. You could choose to send the original signed body (with signature) for verification of the accuracy of your quote, but the quote itself will be signed as part of the reply by the replying agent. Just
[Mailman-Developers] Python remote urllib.request - mailman subscription
Kip Warner writes: Does anyone have any suggestions or other feedback they'd like to share or propose a better solution? The better solution is Mailman 3, which provides a REST API for programmatic administration, but it not going to be considered ready for production use (at least, not unless the admin is a Mailman 3 developer) for several months. The only developer currently working on Mailman 2 at all is Mark Sapiro, who handles maintenance (ie, bug fixes and integration of uncontroversial minor feature patches). I think any change here is likely to be controversial, so won't make it to Mailman 2 in the near future. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]
Daniel Kahn Gillmor writes: The only way that a DKIM check would fail for the given attack, would be if the DKIM included the To: and Cc: headers and the list was configured to reject mail that either (a) failed or did not have a DKIM signature, or (b) did not include the list's address in either To: or Cc:. Is that what you're suggesting? Yes. Validating anything about a given message is a PITA, as you know. I think this is the best we can do with the MTA-level headers (by MTA-level I mean they might be augmented or reordered by MTAs, so we would need a DKIM-like algorithm to sign the header in the MUA anyway). FYI: In Mailman REJECT is a technical term that implies a notification to sender. In context, I assume you meant reject, discard, or [maybe] hold. I don't understand the point of this scenario. X is a valid signature, and there are known to be delays in delivery. X should just be treated as an old signature. the point of the scenario is to think clearly about the relationship between key expiry and message/signature validity, which are distinct but associated things. AFAIK key expiry is associated with signing, not with validation. Associating key expiry with validation would mean you basically can't use expirable keys with mail, and especially not with archived mail. doing decent key management is tricky. Sure, but this particular case is well-defined AFAIK. It's out of our hands. 1) mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message I think this is the right way to handle layered messages when signatures are required. The i tend to agree with you here; but it looks like you might have gotten cut off. did you have more to say on this question? I usually do ;-) but often enough it's sufficient unimportant that I forget. I'm not sure what I intended to say. :-/ Possibly a reference to the idea of encapsulating the whole intended message (especially the originator headers per RFC 5322) in a signed part to avoid the whole can we trust the headers issue. In this format the important headers would be signed, so we trust them as much as we trust the signature. I think we can punt on this. The same way we ever do. Ie, we use a PK certification infrastructure or a web of trust. That's up to the list owner. I think doing proper key management is a lot trickier than that. Of course it is. I'm saying it's not in scope, not for this GSoC proposal for sure, and probably not for Mailman. both X.509 PKI and OpenPGP Web of Trust-style authentication networks have a lot of fiddly bits and ways to get the implementation wrong *and* controls that you might or might not want to expose to the end user. I wonder why they're so fiddly? ;-) And why we should think we can do better? If you're an avatar of djb or Bruce Schneier, say so, and I'll take your word for it. I *know* I don't know enough to make recommendations here, let alone reify them in software. I'm almost certain Barry, Wacky, Terri, Florian, and Mark don't. Nor Abhilash. And for any key management regime: * what do you do with a message that is signed by a key that claims to belong to party X but you can't verify the key identity? Depends on list policy. Default: HOLD. (I'd like to say REJECT, but you don't know you're not creating backscatter in that case.) DISCARD is a more or less plausible alternative, but I haven't thought about it carefully. * Are all kinds of key identity verification failures the same, or are some different than others? (e.g. do you handle messages signed by expired keys different from messages from messages signed by revoked keys?) I would say, not quite, not very, and no for those two cases. I'm not sure this needs an option: both express the sender's intention that the key not be used in this way. There might be options about how to handle it (eg, I suspect that in both cases the most common reason for receiving such a message is pilot error by the sender, but it needs confirmation -- so REJECT; there are arguments for DISCARD or HOLD, though). There are probably more questions for each domain, and more general questions as well. how many of the these decisions do you want to expose to the list administrator? how many do you want to expose to the mailman installation operator? These general questions are use-case-dependent, and therefore the answer now is none of them for the list admin, and all of them for the instance admin (who in general will be the same at this point in history). As use cases arise, we can revise the design. how do you choose good defaults for these choices? Fail secure. What does it mean (socially) to have an open-subscription list that requires signatures from posters? I don't know, and personally I don't really
[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Abhilash Raj writes: This is a list of topics that probably needs to be discussed in detail again. I tried to mention in breif about the discussions in past personally with a someone or on mm-dev list. Please ignore the topics which you feel has already reached a inference. It is a long mail though. * How to ensure the keys belong the email it says it does? This is not in scope for your project. Key upload is for bootstrapping strong authentication, therefore you should assume there is no strong authentication to authenticate the key upload. Man-in- the-middle attacks on the key upload mechanism are *way* above your pay grade. * Inline pgp should be supported or not? Although its not included in one the best practices but some people still use it for the purpose of signing only a part of the email. It depends on how it gets used. If there are MUAs that do this without consulting the user, then we should support it eventually. If it requires a user's guidance to get that result, then we can just tell them Don't do that. You should give a reference for not best practice. * How to handle partial multipart/signed messages? In previous discussion it was pointed out that we should strip off the parts till we actually arrive at a point where the signature verifies all the text and then send that part to the subscribers. Other options were to discard these kind of email or let the owner decide what he wants. I think we should handle it. Among other things, if you want the originator headers signed, I would think the easiest way to achieve that would be to send a signed message/rfc822 part. * Should mailman keep the signature of sender before signing or strip if off? Needs to be an option. By default, the sender's signature should be kept so that recipients who know the sender well enough to have his key can verify it. This may also help with catching key fraud. But as you say it could be used to identify a poster, and that might be bad in some contexts. * Should we make the sending of signed copies of email default? We can introduce an option to send signed email by default for those who want may verify the email, but is there a point in sending singed email when the mails received are not signed? Or this could be a good point? I don't understand what you're suggesting. I think the list should be capable of signing mail itself, even if incoming mail is not signed, yes. For example, posting may only be allowed by the list owner from localhost, and signing is a convenience. * Email interface to manage keys? Mailman has a set of email commands to process the requests for subscription, change password and many other things over email without a web interface, so to allow managing keys over email we could allow receiving signed emails with new keys and command to add them, the confirmation mail for the new key will then be sent to the same address but would expect a signed reply from the new key. Seems reasonable as an extension if you have time. * How are we actually using the web-of-trust model of OpenPGP? We aren't. Simplistic rules like two signatures are not going to be good enough for anybody who cares. Writing a framework so that admins can configure the signature policy is also above your pay grade. You should consider providing hooks for such validation, and maybe a proof of concept implementation to hook into it. Something like a key is considered valid if it is signed by the list-owner. About the implementation I decided to take up with the processing of email part first and then setting up the PKI for the users. The flow would be something like this: * the message is queued in incoming queue * the incoming runner wakes up, finds the message and calls a few functions to verify the signature of the message(assuming the function already has public key of the user from somewhere) I think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking. * If the message signature is found to be valid the message is then passed on to onther runners as usual (without stripping of the signature as per my assumption till now, need discussion on this) else it is dropped or bounced depending on the state of verification( like if the signature is older we can inform the sender as the delay may have been due to smtp deliver and simply drop the message if the signature is verified to be wrong). * Now a valid signature would be a signature signed within 4 days(default and configurable by list owner) from when mailman receives the email.(Is there someway to also check if the signature was previously sent on the list? so that we can block that also?) Here and in the previous
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Not in GSoC scope, this is direct to Barry (and anybody else, including GSoC students of course, interested in core). Barry Warsaw writes: I know this is a little backwards, but it's probably the best match for the current rule/chain model. I have a smallish problem with this model. Specifically, for a list with a maximum size, I think it's probably desirable to do any MIME part stripping *before* the size test. But this doesn't fit the chain(s) - pipeline model AFAICS. I suspect there are probably other such cases where a bit of preprocessing would be useful, in particular if we implement a reencryption facility as Abhilash originally proposed. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Joost van Baal-Ilić writes: Indeed, that could work. Another way to deal with it could be: a key is considered valid if it is imported in the trusted keyring of the current list. And declare deciding wether to import out of the scope of the project. I think that we necessarily have to trust the list's keyring, that's what it's there for. The question is how do keys get into the trusted list. What I had in mind was that signed-by-list-owner would be a reason to import automatically. The model I have in mind is that signing Mr. A's key means the list owner is willing to vouch for authenticity of that key to others, meaning he know Mr. A (including where to find him if he cheats). This is probably good enough for lists where the 3-way handshake (subscribe, request confirmation, confirm) is good enough authentication of the mail address itself. On the other hand, it's still not a strong authentication in the sense Abhilash wants. Mr. A might have tricked the list owner into signing a throw-away key which will be used to spoof Mr. B's email address. A similar trick would defeat Barry's scheme of sending the one-time key in encrypted form, if the bad guy both submits the PGP key and can intercept Mr. A's mail. Both of these schemes have some merit in that there's a very short window of opportunity for the bad guy. Once an authentic key has been linked to an address, authentication is very strong. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Barry Warsaw writes: It's a valid complaint. What I've suggested in the past is that a rule can do some *nondestructive* processing of a message before it makes its decision. The rule would either throw out the results of the processing (possibly leading to duplication of work) or would cache the results, e.g. in the metadata dictionary (possibly leading to a rather large pickle/in-memory data). Yeah, I was afraid you'd say something like that. This could be quite expensive in terms of duplicating work for encryption, but I guess we cross that bridge when we come to it. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Daniel Kahn Gillmor writes: I think Abhilash's question above is a really important question, It is. and one that really should be addressed by this GSoC project. Vetoed (I'm the mentor). Abhilash is welcome to work on key management if he wants to, but he will not be evaluated on it (subject to satisying the need discussed below for a simple, generic mechanism to allow the list owner to conveniently authorize keys without uploading them himself), and he will be warned if it appears that mission creep is endangering the mission. He is also welcome to use any free time he finds to work on encrypted lists, and there's been mention of a conceptually similar project on DMARC implementation (a message-signing technology for use by MTA owners rather than list owners and members) that he may want to work on. Which, if any, to do is up to Abhilash. You're welcome to continue to lobby him to work on key management though (in public, please :-). But let's drop the discussion of a relation to GSoC, please. Abhilash has his contract, and key management policy is not in it. I'm not claiming that the implementation needs to be perfect, but i do think mailman should support something more sophisticated than oh, anyone can just upload a new key via the webinterface. Nobody is saying otherwise. I'm just saying that key management in general is not Abhilash's problem for GSoC. There does need to be a way for list owners to take complete control of key management, and there does need to be convenience in management. I think that the key signed by list-owner's list-key-management-key is an important step for convenience. I suspect that the hook needed to implement it would be able to support various policies (probably through the 'chain of rules' mechanism implemented in Mailman 3 core -- might require some refactoring of core I guess). I like this latter proposal, and it should be pretty straightforward to implement. This means, of course, that the list-owner's key needs to be known to the mailman instance. could there be more than one list-owner's key? Yes. As implied above, I envision there being a specific key used to sign for permission to do X FVO X such as subscribe, post, get member list, sign other people's keys (Web of Trust!), etc, so there could be several keys in that sense. For paranoid folks who regularly expire their keys, I would expect that keys might overlap in time, so there probably should be a list of keys for each function. In some cases one key will fit all, of course: I only sign for people I trust to do everything a signature gives authorization to do. A) if refreshing keys from the keyserver network is something we want mailman to do, when should it happen? how often? Good questions, both the implicit one (do we want?) and the explict ones. Beyond my technical knowledge at the moment, though. B) if mailman can't find a valid key+userid for a known subscriber, when should it query the public keyservers to try to find one? Immediately, subject to the caveat that this would possibly be a separate queue. Oh, I suppose you mean should Mailman automatically add a key that the user may not really have intended to use? That's an extremely complex question. If signed by list owner is the only criterion and it's necessary and sufficient, I'd go with always. Otherwise you have a complex policy, and I'd have to see the policy to know when querying is appropriate. C) how should mailman accept uploads of key material that *don't* go through the keyservers? Please expand. A signed key is a signed key, or isn't it? D) if mailman notices that a subscriber's key has expired or been revoked or somehow become invalid in some other way, is it expected to notify that subscriber of the change in status? if so, how? (i recommend that the answer is no notification, at least in this initial implementation. I would expect that noticing would happen during the process of authenticating a request. If key status *changes* (a key that was never valid for the list should cause silent denial of the request to reduce backscatter), then the user should be notified that key status has changed *and* how that was determined. Anything else is going to leave the list owner in the dock. Also, the key owner may wish to prosecute somebody for misuse of her key, and should be informed of the misuse. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Daniel Kahn Gillmor writes: Maybe we're not talking about the same thing. OpenPGP certification should be identity certification, and nothing else. trying to extend OpenPGP certification to mean something other than identity certification sounds like a bad idea to me -- it breaks all kinds of other assumptions within the OpenPGP world. I was thinking that the baseline is: 0) each e-mail list has a set of identity certifiers Yes. 1) each identity certifier is itself an OpenPGP primary key fingerprint (or, the primary key itself). Yes. Probably the primary key. 2) subscribers to an OpenPGP-enabled mailman mailing list subscribe, unsubscribe, receive, and send mails as usual (though messages not signed with valid keys will not be re-sent to the list). Not necessarily. It may be necessary to sign admin messages as well (subscribe, unsubscribe, set vacation) Your phrasing presumes that the only role of Users (the internal representation of an identity) is to act as a subscriber who reads and posts. The way I think of it is that Users may have several roles (read, post, moderate, admin) for each list. Each of these roles may be certified by a different agent of the owner, where agents are represented by different keys. 3) if a signed message comes in, the server checks to make sure that the message is signed properly with a key that is certified (by one of the list's identity certifiers) to belong to the person in the message's From: header, *and* that person is a known subscriber to the list. Known subscriber doesn't really make sense in the Mailman 3 world. There are Users, they can be members of a list (ie, known to the list) and they can have roles (reader, poster, etc). It's not clear to me that requiring posters to have the reader role in this world is the right way to determine membership. so when you say certified key above, i think you're talking about what is known as a valid key -- that is, the relevant user ID is bound to its primary key by a certification made by one of my trusted identity certifiers. That seems to be nonsense, though. Key-to-UID binding is done by the user database; it's only meaningful inside of Mailman. A signature on a key is not a way of making an authenticated link to a UID in Mailman, AFAICS. It's only a of certifying that the signer knows the keyholder and that this is that keyholder's key, and that the signer trusts the keyholder not to allow others to use her key. That doesn't mean (in the absence of actually binding a UID to the key *in* the certification) that this keyholder corresponds to any given UID. So this interpretation is useful only if a new UID is being assigned to that key in this transaction. It doesn't work if we are binding a new key to an existing UID. I also don't see why, in a web-of-trust model, you would want to use that definition of valid. (If the key is determined to be none of corrupt, expired, or revoked, I would call that valid.) A key not signed by a trusted certification key would be (completely) untrusted, but you can imagine various degrees of trust. For example, in a member recommendation model, you might allow any member's key to certify the reader role but not the poster (or vice-versa for a list handling privacy issues!) Having validity depend on trust makes the concept of validity quite ambiguous. I would interpret a certification expiry differently: as the period of time for which permission to register the key is valid. If we want an expiry for User authentication, probably a generic tool for managing that in Mailman itself would be sufficient for this purpose and useful elsewhere. certification expiry means i am willing to claim that this key belongs to this person for N months; if it's later than N months, and you don't see a newer certification from me, please don't rely on my claim any more. I think it would be a mistake to interpret that any other way, I don't interpret it any other way. I'm assuming that once the key is registered, Mailman and the list owner take responsibility for trusting keys, and they no longer rely on the certification at all. If the list owner wants to use the certification in authenticating the User, that would be OK. But then the temptation to use an infinite expiry would be strong (unless a mechanism is provided to make re-signing convenient -- but not *too* convenient: sorry, no re-sign all button will be provided!). With infinite expiry certification is meaningless in the long run (in the long run we're all dead, and a signed message from someone known to be dead should be a clue...). since that is the default interpretation of other pre-existing OpenPGP clients that will be seeing these same certifications. Why are they delegating so much power to the certifications? That seems very strange to me. I certainly wouldn't stop trusting a key that had been used to sign messages
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Daniel Kahn Gillmor writes: On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote: The way I think of it is that Users may have several roles (read, post, moderate, admin) for each list. Each of these roles may be certified by a different agent of the owner, where agents are represented by different keys. It sounds to me like you're trying to use OpenPGP keys for authorization here, rather than for authentication. I think that's a mistake. A certification is a statement that *I* know *this* key to be associated with *that* person, and only that person. Depending on the value of I, you may extend different levels of trust to that person. You're already down the rabbit hole, my dear Alice. The question is whether to eat the red mushroom. ;-) OpenPGP's so-called web of trust is a network of identity certifications; it does not typically include authorization information. There's no authorization information in the web of trust. The authorization decision is made on the basis of being presented a signed key; that's all Mailman has to go on. Depending on the identity of the signer *Mailman* may grant additional authorizations. Consider the example I gave of subscription by member recommendation. This is limited scope is actually a feature, for (at least) three reasons: 0) OpenPGP certifications are typically public If you don't want to expose different roles as OpenPGP identities, don't. Nevertheless, the capability is available in OpenPGP: the identity-to-key mapping is not one-to-one. 1) because OpenPGP certifications are statements about identity, you can perform some reasoned inference about them The whole point of the suggestion is based on this fact. There's no authorization in the signatures. Mailman makes decisions about the authorization to grant based on the identity(s) of the signer(s). 2) because the certifications are just statements about identity, they are easier for most users to make; Sure, but some users are smarter than the average bear, or have requirements beyond those of a typical panda. Known subscriber doesn't really make sense in the Mailman 3 world. There are Users, they can be members of a list (ie, known to the list) and they can have roles (reader, poster, etc). It's not clear to me that requiring posters to have the reader role in this world is the right way to determine membership. i'm just suggesting that those roles are authorization statements about users and lists. They are. We're just confused about user. I mean Mailman User, you mean PGP userID. They're not equivalent, at least not at the stage of adding a key to a User in Mailman. so when you say certified key above, i think you're talking about what is known as a valid key -- that is, the relevant user ID is bound to its primary key by a certification made by one of my trusted identity certifiers. That seems to be nonsense, though. Key-to-UID binding is done by the user database; it's only meaningful inside of Mailman. The key-to-uid binding is done by the OpenPGP keyring. this is the entire point of an OpenPGP keyring: given a signed message and a from address, can you confirm that this message really came from the stated from address? No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because addresses are *not* Users. There is a many-to-one (address-to-User) mapping (I hope; if it's many-to-many, we can probably dodge that bullet by allowing sets of Users in many places we'd normally expect a User). However, binding an email address to a User is a Mailman operation, and at the point of adding an email to a User, in the scenario I'm thinking of the only thing Mailman has to go on is the association of a key to an email. If this is the initial email for that User, there's no problem. But for additional emails, there *is* a problem. The identification of existing emails with the email to be added is not necessarily guaranteed by the key presented. We need to think carefully about how this works (or can be subverted). I don't think i understand what you're saying. when Alice makes an OpenPGP certification on Bob's key (Alice signs Bob's key), she is explicitly binding Bob's User ID to his public key. So saying in the absence of actually binding a UID to the key in the certification doesn't make sense to me. Mailman UID != GPG UID, at least not at present, and probably not for the foreseeable future. It's not surprising that these terms still confuse people; they were muddled even in the GPG documentation up until a few years ago. It's worth clarifying them explicitly: * A literal key (nothing but a key, no UIDs, no self-sigs, etc -- not an OpenPGP certificate) that is well-formed is syntactically valid. * a syntactically-valid key whose certifications we are willing to rely on when evaluating other keys and user IDs is a trusted
[Mailman-Developers] Message Handling Workflow
VuNghia Truong writes: Could any one please help me to answers these questions: - Is the handling workflow b.t version 2 and 3 the same or different? It's different. V2 has a single pipeline that both checks the mail for conformance to list regulations and also cleans up the post (removing forbidden content types) and adds list-specific content (mail headers, leader and trailer parts). V3 has two separate pipelines, one for approving the post (using chains of rules) and one for preparting for distribution (using a pipeline of handlers). Be carefule because the terminology resembles that used in V2 but the architecture is definitely different. - How the file system are organized, how these pieces of codes fit together? The /var hierarchy for Mailman 3 is quite similar to that of Mailman 2. I'm not sure what the installed code looks like; we currently recommend running in a virtualenv, basically everything in the source tree. The source hierarchy is quite different. There are altogether 4 separate source trees: - Mailman 3 core: the post distribution and databases - mailman.client: helper library for accessing database and configuration using the REST (HTTP) interface - Postorius: the web admin interface (including user subscription options), which depends on mailman.client - HyperKitty: the archive management and web access interface. Note that Postorius and HyperKitty are designed to function as independent modules, and are basically independent projects. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
Murray S. Kucherawy superu...@gmail.com writes: Hey, I've been trying to find the superuser at Gmail, and it turns out I've known him all along! Would you please fix the breakage where copies of one's posts aren't delivered to yourself, which is a real PITA when trying to diagnose Gmail problems?wink/ (BTW, did you try to sign up as root? or Administrator? ;-) I'm all for experimentation and being adaptive as new things come along, and I'm obviously supportive of the DMARC effort. That said, I hope that these are going to be configurable options, defaulted off for backward compatibility. I second your concerns in principle, but I don't think you need to worry about these features being anything but optional. I suspect that a majority of our user don't actually have the fine control over their DNS needed to implement DMARC. (a) the second bullet above is a significant departure from current use Violating the RFC by munging From (for heaven's sake! have we learned nothing from the sad history of Reply-To munging?) is simply not acceptable for most purposes, although perfectly acceptable for advertising. ;-) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
Franck Martin writes: If the From: contains the posting email of the mailing list, one would think that the default becomes reply to the list, but this is where Reply-To: can be used. Most users do not display Reply-To; many cannot (at least not at their level of technical skill). This means that they get no indication of the author of a message unless the author signs the body of the mail, which often isn't done, and is impossible to enforce. So this setting is simply unacceptable except on announce/advertising lists (where Reply-To is usually set to some other address anyway) and on anonymous lists (which as far as I know are relatively rare). If this option becomes a popular filter on large mail hosts, discussion lists (ie, the kind of mailing list that Mailman was originally intended to serve) will take a severe, perhaps fatal, blow. I hope this helps alleviate concerns. Unfortunately, it doesn't. Imposition of authentication designed for personal and other direct mail on aggregate-and-forward services like Mailman is a knife at our throat in principle. Despite obvious goodwill on the part of IETF and others involved in the discussions, I have seen no proposal that works well for discussion lists as currently constituted. And, even more unfortunate, there is ample evidence that the large freemail services (including AOL), not to mention many inexpensive hosting services, consider the possibility that even one spam gets through a knife at *their* throats, while non-delivery of legitimate mail is no problem because it can always be blamed on somebody else.[1] I fear that any halfway plausible plan (even one as flawed as Gmail's handling of own posts) could get quick and widespread adoption if Mailman offers such features, and operators of discussion lists will be blamed for their poor attitude toward spam-fighting when they resist using them. One might also speculate that the big portal operators are strategicly hostile to independently operated mailing lists, as they would like people to use their forum services instead. But that's purely speculation. None of this is your fault or Murray's, or DMARC's or DKIM's (despite its yahoo roots). It is, however, a reality that *we* face. PS: Stephen, Murray does not work for Google, and therefore cannot change the way gmail works. I'm aware of that. I was ribbing him for his choice of mailbox at Gamil. He obviously thinks it's funny; nobody imposed it on him! Footnotes: [1] For example, my University's Information and Media Center (which intercepts all SMTP connections, and likes to think of itself as in the same class as the MIT Media Lab) labelled Murray's mail [Suspected Spam] in the Subject field (which I removed in the interest of remaining friends). I can't even rely on the [Spam] label when applied by their incompetent filters. :-( ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
Franck Martin writes: This is speculation, I said so myself. The fact that I'm paranoid just means I've read Bellovin and Cheswick. and broad fear of the future... No, it's an extrapolation of my own occasional experience, and the frequent pain of others that I see on this list, and the observed behavior of sysadmins, some of whom I respect but who are under extreme pressure to stop spam, and others who are less competent. It's a very specific fear of a broken standard that may be imposed on us by powerful third parties. It's possible that mailing lists as we know them today are an anachronism, that they themselves are fundamentally broken in a world where spam constitutes 90% of all email traffic, and we should let them go rest in peace. I can accept that. There may be no solution that allows both existing mailing list customs to continue and provides socially acceptable levels of spam prevention. If so, so be it. I hope this helps alleviate concerns. You should really read the code of the patch for MM2 and try it. I don't need to when you suggest violating basic RFCs to make DMARC work better. Sometimes it's appropriate to take ownership of From. DMARC is not a valid reason to do so, and I'm not going to try that. And what good does trying a patch do? I fear a *social* problem, not that your patch will make Mailman technically unable to receive or send mail. If the latter happens, we debug the patch. Minor irritation, no more than that. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
SM writes: Hi Stephen, At 18:39 08-07-2013, Stephen J. Turnbull wrote: work better. Sometimes it's appropriate to take ownership of From. There is a case where the mailing list administrator configured the list to take ownership of the From. Telling people that it was not a good idea never works. It's easier to wait for the denial of service (which happened) and watch the complaints to pour in. It doesn't work on people who convince themselves it's the only way to solve their problems. It often does work on people who are grasping at straws, and know it. You can often convince the latter that they'll only make their problems worse. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
Franck Martin writes: We are not asking mailman to do the work of DMARC here. There is openDMARC for that. Of course you are, in feature #1. Unless you take it literally (reject all email that comes from such a domain, *including* email that would authenticate correctly in a full DMARC implementation). I think that the appropriate interpretation of that feature request is that in some cases, Mailman needs to play the role of MTA in the DMARC protocol. Anything less than a full implementation is a denial of service and screws everybody: the domain owners, the recipients, and the Mailman site admins, list admins, and moderators. And us, who will take the lion's share of PRs for it even if it's a third-party module. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
Barry Warsaw writes: On Jul 11, 2013, at 03:23 AM, Stephen J. Turnbull wrote: This is somewhat problematic. DMARC results are potentially trivalent. If action is reject and pct is less than 100, some hits are rejects and some are quarantine. Misses are misses. So I guess you do this with a chain of two rules, the first one verifying the message and if that hits (ie, verification fails) the second one rolls the dice for pct. While ugly, that might be the best we can do for now. Verbose, yes. Is it really ugly, though? I don't know how much you were directly influenced by iptables and SIEVE, but the idea of rule chains as a way to very flexibly configure filters has been implemented many times. The model is very simple and completely flexible. Instead it would jump to a custom (terminal) chain that made the more specific determination of whether to reject or hold the message. This is pretty much what I was suggesting. Silent discards without content analysis make me queasy. Of course, we'd likely log and fire an event, so at least it wouldn't happen completely silently. No, but it might be many days before the originator gets around to asking why their message hasn't appeared. Yep. There is some limited ability to do additional checking at LMTP time, but this isn't pluggable currently. Does LMTP provide the necessary ability to reject? Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
Barry Warsaw writes: On Jul 12, 2013, at 11:56 AM, Stephen J. Turnbull wrote: Yep. There is some limited ability to do additional checking at LMTP time, but this isn't pluggable currently. Does LMTP provide the necessary ability to reject? Not reject in the Mailman sense of sending a bounce message (possibly DSN formatted), but it could refuse to accept the message from the LMTP client. That's what I meant. With luck, then, the LMTP rejection could happen during the MTA's SMTP transaction. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3.0 todo list
Geoff Shang writes: The reason why I'm asking is that I'm in need of some Mm3 features and was wondering if it was ready for limited deployment, and if so, what those limits currently are. The list server is in beta, when combined with Postfix as the MTA. Interfaces to other MTAs have not yet been created yet. The archiver and the web interface are at best early beta, but there are running prototypes. You can substitute a 3rd party service like mail-archive.com if that is satisfactory. The User model remains somewhat incomplete. By that I mean that we don't have a successful integration of Mailman users with enterprise user databases. The linkage seems a bit ad hoc in the prototypes that GSoC students are working on. There are no deployments I know of, although Barry may. (I'm leaving out people who are playing with betas; by deployment I mean supporting real work.) The GSoC mentors and students are discussing setting one up that we can experiment either. HTH Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3.0 todo list
Barry Warsaw writes: On Jul 15, 2013, at 01:21 PM, Stephen J. Turnbull wrote: The only thing I can think of offhand for core is Exim support. (Sendmail support, I suppose, but nobody I know uses Sendmail, and I can't do it. Exim on the other hand is on my personal list.) I'd very much love to have Exim and Sendmail support. If you're an expert I'm not an Exim expert, but on my personal list means I'm going to start working on it tomorrow [or a little later due to Terri's recent edict to GSoCers]. I'll be happy to compare notes or pair program or whatever floats boats with anybody else interested. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
ehr...@greenhouse.economics.utah.edu writes: I am not an expert but the encryption discussion is extremely important. We are not currently discussing encryption, but rather signing. A similar approach might work for signing, but it's subject to a weaker form of the objection below.[1] Are you familiar with the Secure Email Lists (SELS) project? It's been mentioned. To my limited understanding it seems to have the perfect solution for mailing lists. Nothing in email is perfect or as simple as it seems. :-) From skimming your messages I did not have the sense that you were discussing such a paradigm. We aren't. This paradigm has a serious security hole from the point of view of Mailman in that many lists consider the filtering services (ie, blocking certain MIME content-types) to be essential. Since the MTA cannot decode and Mailman doesn't decode messages, there is no way to prevent distribution of malware. This would at the very least be a serious embarrassment to the operators of the allegedly secure list, and in my experience a serious danger, as I know very few people who treat secure systems as anything but absolutely safe, ignoring the fact that any given security system can only handle the attack vectors it was designed to handle. It might be useful to add it as an additional service, but given the responsibility that mailing list admins are expected to shoulder in today's environment, I think it's essential that the admins have access to the content distributed by their lists. Steve Footnotes: [1] Although filtering is possible, the approach you describe would require whole messages rather than parts to be filtered AFAICS. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] How to check whether the message is new thread!
VuNghia Truong writes: Could any one please give me advices about how to check if a message is a new thread or just a reply to a thread? Check for a References: header or an In-Reply-To: header. These headers contain message ids from the thread. If they aren't present, the message starts a new thread. Technically, the presence of these headers *defines* thread. In practice, you may also want to group messages with the same subject in the thread. However, there is no good way to determine order without the References or In-Reply-To header, so for most lists it is not worth the extra effort to analyze two headers to see if they're really the same after stripping out various prefixes and affixes added by software along the way. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3.0 todo list
nkarageuz...@gmail.com writes: I'm looking forward mailman 3 to find efficient archive UI, with posting from web feature (just like in http://groupserver.org/) I don't see a reply, so even though I'm not the best person to answer this I'll take a hack at it. There were two or three proposals related to this feature for GSoC this year. The one directly targeting this feature didn't make the cut. There's another, more ambitious, project to create a user interface for reading, posting, archive browsing, and user profile updates, which is being supervised by a mentor from the Systers. However, neither of these seems like it will be ready for prime time soon. I don't think the student who proposed the feature to Mailman was serious about it, he was just hoping to get a GSoC internship. I doubt he's working on it (anyway, we haven't heard a peep from him since). The Systers student is working on something specifically for use of Systers, and I don't know whether we can integrate it into Mailman 3 directly. Should i consider pipermail or Postorious for rendering ? Pipermail is dead. Postorius is an option for UI, but it's not really about viewing or posting messages, it's more for admin (both list and user profiles). The archive manager under development currently is HyperKitty, which you can find out more about from https://github.com/hyperkitty/hyperkitty. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Barry Warsaw writes: On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote: [1] Has anybody else noticed that both gpg's UI and its documentation seem designed to make it as hard to use as possible? Sadly, I think this is one of the biggest reasons why we've never seen widespread adoption of signatures and encryption in email. Sure, but the wrappers I've seen don't really help. I get the feeling that they are basically designed around smebody's personal needs with all kinds of bags and kludges added on request. Maybe you can sprinkle RDM with itch powder the next time you see him? I bet he could do for a gpg wrapper what he's done for the email package! }:-} ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Abhilash Raj writes: I think the address should be $LIST-owner@fqdn. For other parameters, defaults are OK I think (size=2048, type=RSA IIRC). Here should not the address be the list's posting address? Like for mm-dev list should it not be mailman-developers@python.org? Maybe. But in most cases the sender is not going to be the list, and it's possible to configure the list so that the list-post address doesn't appear in the header. So I don't think it matters much. I just tend to associate signatures with people rather than bots. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Get message content by message ID
Nghia Vu Truong writes: Is there any way to get message's content based on its Message ID? That depends on where the message is stored and what features that store implements, and where and how you want to fetch messages by message ID. If you're using a standard Mailman installation with the bundled archiver and no third-party software, the answer is no. Specifically, in the case of Mailman 2, there is an internal store for the queues while processing the messages, but no way to access queue items by message ID. Most sites use the bundled pipermail archiver to store archives for access by list subscribers and the general public. It provides no search features at all, so there is no way to search on message ID. In the case of Mailman 3 (in development), the same analysis applies to queue items AFAICS, and there is no bundled archive manager. The most likely candidate for recommended (and possibly bundled) archive manager for Mailman 3 is HyperKitty. You'd have to ask its developers (but it's not ready for beta test yet AFAIK). If you're using a third-party archiver with search features, the answer is probably yes, but we can't help you with third-party archivers (at least, I can't). ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Daniel Kahn Gillmor writes: On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote: Python 2.7.5 (default, Aug 1 2013, 23:58:20) from gnupg import GPG gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') crypted = gpg.encrypt(u'A bit of random text.', u'step...@xemacs.org', always_trust=True) hmm, always_trust=True is probably problematic Of course it is, but I was working with a test keyring. -- if someone manages to inject another key with the associated User ID earlier into gpg's keyring, then their key will be used before the correct key. This is an argument for validity checks on the keyring. The alternative is keeping the email-to-fingerprint mapping in the User database, which is *not* designed for crypto validation. I see no reason to suppose it's easier to attack the keyring that the User database. fortunately, in the current implementation we're only worrying about signing, not encryption; so the relevant issue is the choice of secret key, and we don't expect other users to be able to inject data into the secret keyring, so this shouldn't be a concern. right? I don't think it's a major concern, period. True, encryption uses the public key, which may be downloaded from a keyserver or entered from the web, making injection attacks plausible. So what? What's the alternative given that the raison d'etre of Mailman is to give users control over their profiles? Note that I don't deny that there are real security issues here, and that in some contexts they are important. But if they are, I have to wonder if Mailman isn't much too complicated to be trusted anyway. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] virtualenv and nose2 replace zc.buildout and zope.testing
Barry Warsaw writes: A while ago I mentioned that I was trying to get rid of zc.buildout to build Mailman 3 and zope.testing to test it. This work is now complete and pushed to trunk. Yee-haw! (and giddyap, GSOC students! fix them tests!) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Daniel Kahn Gillmor writes: On 08/28/2013 09:37 PM, Abhilash Raj wrote: 1) There is a 'signature rule'[1] that can verify signature from the users whose public key is stored in 'var/gpg' directory insider 'pubring.gpg'. This rule also verifies that the email has only two parts one of which must be 'application/pgp-signature'. i'm not sure about this last constraint. It's certainly possible to have a multipart MIME message with a deeper structure that has more parts if you're looking at the leaves of the MIME tree. the constraint should be: main content-type should be multipart/signed; that part should have exactly two immediate children; the last child should be application/pgp-signature. The first child could itself be multipart/mixed or multipart/alternative. The last time I looked (~10 days ago), that was the implementation: look only at the message-level Content-Type, ensure it's multipart/signed, check that there are exactly two parts and that the second is application/pgp-signature. Note that nested multipart parts are problematic. You can't strip unwanted parts from them (many lists strip .exes, others text/html, and so on) without breaking the original signature. We need to think carefully about what policies to support regarding signed multiparts. I would suggest that the initial default policy should be (1) verify the signature, if not DISCARD (2) if valid AND key belongs to explicitly allowed poster (I think probably nobody wants open-post signed lists, but what do I know? ;-) AND signed part is multipart, REJECT with multipart not allowed for technical reasons as reason (3) if valid AND key belongs to explicitly allowed poster, APPROVE (4) otherwise HOLD while we're figuring out a sane UI for configuring more complex policies. have you tested what messages with this structure look like when viewed with any MUA that is PGP/MIME-aware? +1 do you have any examples you could publish, so other people can test other MUAs? +1 please do not use pgp.mit.edu [0], it is out of date and poorly-maintained. Your best bet for reliable, redundant service is to use ha.pool.sks-keyservers.net. You can read more about this high-availability DNS round-robin pool on the sks-keyservers website [1]. Thanks for the suggestion! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Updates
Daniel Kahn Gillmor writes: On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote: The last time I looked (~10 days ago), that was the implementation: look only at the message-level Content-Type, ensure it's multipart/signed, check that there are exactly two parts and that the second is application/pgp-signature. hum, what if the first part is an .exe of type application/octet-stream? :P Windows users get another reason to switch? ;-) That should be handled by content filtering. *However*, content filtering needs to be taught to throw away the signature too if a signed part gets filtered. Doesn't this seem a little overbroad? what if the message is two inline parts, one text/plain and one text/x-diff (e.g. the common case of someone sending a patch to a project mailing list ? I understand wanting to REJECT if any of the internal parts need to be stripped, but if none of them need to be stripped, it seems like REJECT is too heavy-handed. Sure, but there's a GSoC scope issue here. Principle Number One has to be Better Safe than Sorry, and this is easy for Abhilash to implement safely. It has to be an option, of course, for admins willing to risk junk getting through (eg, because their users don't use Outlook [Express]). Or is the knowledge about what might need to be stripped not available at that stage? If the stripping happens later, can we mark a message as REJECT if you need to strip somehow, and get the part-stripping code to respect that marking and REJECT it there? I doubt that Abhilash knows, and I know *I* don't. :-) My guess is that signature check in principle is going to be a Rule, while part-stripping is a Handler. I don't think Handlers can REJECT, Rules make that decision, and they come first, before the Handlers. So I see the process as involving two Rules. The first one checks the multipart/signed message itself. If invalid (either a broken signature or signer is not allowed to post), DISCARD (the risk of a spoof is too great). The second one checks the structure of the message. Presumably code can be reused from elsewhere to do this with more accuracy as you suggest, but the easy check is to disallow multiparts nested in multipart/signed. My proposal at this point is to accept an easy and safe (== restrictive) implementation for the purposes of GSoC and early beta testing. I don't mean to suggest it's at all satisfactory for a public release of this feature (although we might all be surprised and find out that it's fine for many purposes!) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Can we send message with attachment using UserNotification?
Mark Sapiro writes: On 08/21/2013 02:02 PM, Nghia Vu Truong wrote: Hi there, Could you please help me with this question! Is there anyway we can attach a document to message, sending by UserNotification method? No. Mailman.Message.UserNotification() creates a single part, plain text message. I think the odds are pretty good that a uuencoded appendix would get through. But it's probably risky these days, especially if people are using recent entrants ( 10 years old) in the MUA market. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Testing different email structures with MUAs
Abhilash Raj writes: I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure. I don't understand what you think you will learn from this experiment. We're not interested (for your purposes) in what MUAs do with broken messages, including those that can't be validated. Your code simply should never emit them. (OTOH, we are interested in what your code will do with broken messages: it should trap them.) In particular, in most cases the MUA will parse the multipart structures and tell you what they've found in one way or another. This is true of signed message parts. It's not unreasonable to suppose that some messages will contain additional content after the signed part; the MUA needs to determine the boundaries of the part in any case. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Testing different email structures with MUAs
Daniel Kahn Gillmor writes: On 09/11/2013 08:44 PM, Stephen J. Turnbull wrote: Abhilash Raj writes: I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure. I don't understand what you think you will learn from this experiment. We're not interested (for your purposes) in what MUAs do with broken messages, including those that can't be validated. Your code simply should never emit them. (OTOH, we are interested in what your code will do with broken messages: it should trap them.) I think Abhilash is modeling what the messages emitted by a re-signing mailing list might look like. Yes, I know that. I don't think his proposed experiment is valid, however; he needs to use messages with valid signatures, because that is what Mailman will produce. He's created these messages so that people can view them in their OpenPGP-compatible MUAs and see how the message signatures are displayed to the user. And if they do anything but display a warning that the signed part didn't correctly validate and are you really sure you want to look at the possibly radioactive waste in the payload?, they're broken, no? But that's not our problem, and it's especially not Abhilash's. In particular, in most cases the MUA will parse the multipart structures and tell you what they've found in one way or another. This is true of signed message parts. It's not unreasonable to suppose that some messages will contain additional content after the signed part; the MUA needs to determine the boundaries of the part in any case. I'd actually argue that it *is* unreasonable in the current ecosystem to include some non-signed content after the signed part. You've got the wrong end of the Postel principle. I'm saying you will *see* such mail, not that you should *produce* it. You immediately provide evidence that it's common, and that at least one OpenPGP- wannabe does the wrong thing with it! Most OpenPGP-compliant MUAs that i've seen (thunderbird+enigmail in particular [0]) cannot clearly indicate to the user which part of a multipart, partially-signed message was the signed part. Wonderful. :-( If we could make mailman tuck its footer within a larger signature, that would be great. So you're proposing this, I guess: multipart/signed multipart/mixed text/whatever # optional mailman header multipart/signed text/whatever # original signed content application/signature text/whatever # optional mailman footer application/signature But the question is not whether Mailman can do that; it's trivial to produce it by moving the signing handler later in the pipeline. The question is whether OpenPGP-wannabe MUAs will do anything reasonable with it, FVO of reasonable that include letting the user know what exactly was validated. Do you really think MUAs will do anything reasonable with it when they do this: Mailman is perhaps the most common generator of messages like this, such that icedove+enigmail currently makes the tradeoff to permit what is effectively a known signature-validation spoofing attack rather than make people think that mailman is stripping signatures from their messages. I don't believe my eyes. The MUA is passing off invalid data as valid, and you're saying Mailman should cater to that MUA? The sooner users realize such MUAs are broken by design, the better! Better they should bitch about Mailman (at least on Mailman channels, where we can explain to them what the real problem is). Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Testing different email structures with MUAs
Daniel Kahn Gillmor writes: I'm just pointing out that mailman commonly produces what you've called invalid data, In the OpenPGP sense that the whole message cannot be considered to be validly signed, even though it may contain a multipart/signed part with a valid signature. and that its common production of that invalid data is precisely what this MUA's author cites as something he wants to be able to validate instead of hiding the main message contents' openpgp signature entirely. [0] How is that relevant to us? No matter how you slice it, if Mailman does its thing of adding a header or footer, the MUA has to dig into MIME structure and validate a subpart. Sure, in Abhilash's scheme Mailman will be validating the subpart as a service to lazy (?) or anonymous subscribers, but a PUCT[1] will want to double-check that Mailman did what it claims to do. But producing messages is what mailman does, so maybe we fix the message-producing mailman wackiness on the mailman list It's *not* wackiness. It's perfectly standard-conforming, and I see no reason why people who currently don't sign messages, and don't want to ask Mailman to do so because the necessary infrastructure is user- hostile, should be punished or be criticized for producing such messages. My point is that I have no objection to trying to create valid messages that will validate correctly on as many MUAs as possible. What I object vehemently to is the idea that what a broken MUA (such as TB-E) does is a valid test of anything Mailman does. Especially not with a broken message. I also have no objection to Mailman lists simply signing everything, so that they can advertise that they do. (OTOH, this is already more or less fulfilled by DKIM, so it's a niche use case.) Footnotes: [1] Paranoid User of a Certain Type. Ie, trusts the author but not the list. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list Replace the sender Before you release, s/sender/author/, please. When discussing Internet email, sender != author. The name of the feature, author is list, is an obvious falsehood: lists don't write posts, they relay them. These policies do not conform to the email RFCs. (Given the semantics of From set out in RFC 5322, they may even constitute copyright infringement in the absence of a license from posters permitting From-munging. But that's not the topic here.) AFAICS there's an easy way for Mailman to adapt to DKIM without violating RFC 5322: wrap every message in a MIME message/rfc822 part (ie, every message is a one-post digest). The wrapper message obviously can conform to DMARC (From: LIST@DOMAIN with appropriate DKIM signature), and Mailman can DTRT with the wrapped message. with the list address to conform with policies like ADSP and DMARC. It replaces the poster's address in the From: header with the list address and adds the poster to the Reply-To: header, Another RFC violation. :-( What if the poster already set Reply-To because she *doesn't* want mail at the From address? What if the list's address *isn't* in Reply-to, but the author expects wide replies to go to the list? but the anonymous_list This is probably OK. and Reply-To: header munging settings below take priority. Does this make sense? See above. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. Please change this to This setting is useful when your host signs outgoing mail according using DKIM. As written, the advice is inaccurate anyway. DKIM requires more than just MTA settings. There must be cooperation from the nameserver. Usage of this feature on lists have indicated no adverse issue for the members, s/no adverse issue/only minor annoyance/ (I disagree with minor, but sure, Outlook users probably won't notice). You should remember that Reply-To munging works as expected for almost all subscribers almost all the time on most lists, and for that reason is widely used despite its ex post obvious deficiencies. When it fails, though, it's at minimum a minor pain in the ass and at maximum an inadvertant privacy violation. Please go slowly on screwing with From, which (unlike Reply-To) is a required field and so appears in *every* email and has well-defined semantics *with which this feature is in deliberate non-conformance*. provided proper communication is done when the feature is enabled (as to allow inbox rules to be changed if needed). Isn't this a lie? If the From header is corrupt, then there is no reliable indication of who the author is. If you're lucky you can fish it out of the body or .signature. Reply-To won't do: not only are its semantics such that there's no guarantee that it's an alias for author, but it complicates the rules significantly because you need different rules for From-corrupting lists and other lists and non-list mail. In the 2.1.16 Release Candidate the feature author_is_list is controlled by the following switches in the mm_cfg.py ALLOW_AUTHOR_IS_LIST = No DEFAULT_AUTHOR_IS_LIST = No The first one will enable the GUI to present an option to the list admin to enable the author_is_list feature, the second controls if new lists or upgraded lists should have the author_is_list feature set to yes Upgraded lists? If upgrading to Mailman 2.1.16 causes all my lists to be corrupted by this feature, I will not be pleased. An option called DEFAULT should only apply to new lists. If you insist on making this a fallback if the list doesn't have an explicit setting, call the option AUTHOR_IS_LIST. While it is better for the MTA to DKIM sign emails if author_is_list is enabled, this is not a requirement and the list will work fine without DKIM. But why would anybody want to do this in the absence of DKIM? Mailman already has the RFC 2369 and 2919 fields to tell MUAs that it's a list post, and a plethora of ways (Subject, header, footer) to tell users that it's a list post. Anonymous list is already an option for obscuring the author if that's desirable, and for an announce list there's no problem, as the list (or an officer of the host) is already the author. I think you should just delete that sentence. While DEFAULT_AUTHOR_IS_LIST is important to avoid new lists and upgraded lists change behavior, setting ALLOW_AUTHOR_IS_LIST to Yes does not change how any list is handled (author_is_list in the GUI is No by default). it only provides an option to the list admin to change the list behavior. Unfortunately some list admins cannot edit mm_cfg.py (like CPANEL type install), therefore it would be nice to remove ALLOW_AUTHOR_IS_LIST or set it to Yes by default to let the list admin decide how he/she wants the list to behave. Otherwise the list admin
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Mark Sapiro writes: Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail, That's nonsense. There's no reason to do this in the absence of correct DKIM signatures by Mailman or its MTA, and every reason (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so. Of course if the point is to violate the RFCs, then this will still violate the RFCs without the MTA and DNS changes. But surely that's not what Franck means by useful. The whole point of this option is to allow lists to do what we've come to expect them to do (discard or quarantine attachments, add header and footer text, munge Subject) while still presenting a valid DKIM signature to the receiver. Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it. Too late. The reason we should consider adding this feature at all is that the big email providers are heading in the direction of imposing that responsibility whether list owners want it or not. The only real alternative to DKIM signingby Mailman or its MTA is to pass the original message through, optionally with additional headers (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing signatures won't be corrupted. There is an alternative to From-munging, though, which is to encapsulate the whole message (either as message/rfc822 MIME type, or as a one-message digest). Then the Mailman host can DKIM sign the wrapper message without invalidating the signature on the main message. In theory this could also be done with a multipart/mixed (*not* multipart/digest), with a structure like multipart/mixed text/plain; Mailman list header message/rfc822 text/plain; Mailman list footer I have no idea what MUAs would do with that, though. :-( All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default. If the Mailman host is using DKIM, then list owners will definitely want the option available. So site owners should have to make a conscious decision to shut it off. On the other hand, since it does involve a serious systematic RFC violation, I think it would be a good idea to eliminate the DEFAULT_AUTHOR_IS_LIST option. Ie, require list owners to set it explicitly, or site owners to hack code. See my reply to Franck for more detailed comments on the actual proposed changes. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: we (the people using DMARC) have the opportunity to build adoption. Just trying to reduce adoption friction ;) The direction you're heading will *create* adoption friction. The only way you're going to be able to sell this to admins like me is to wait until our users start getting unsubscribed because of DKIM bounces. Otherwise, I'm going to prefer RFC conformance and not messing up my users' rules (eg, killfiles) and autocitation functions. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly. Nonsense. Here's what RFC 5322 says: The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The list obviously isn't responsible for the writing of the message body, and you could argue that in adding header/footer and munging attachments and Subject field it's acting as the agent of the author, who is therefore responsible for them too.[1] If that's not convincing, ask any of your users if they think the list is an author of their posts, or anybody else's. OTOH, if you want to make an authorship claim validly, there's an easy way to accomplish it: encapsulate the whole thing in message/rfc822. Steve Footnotes: [1] Note that RFC 5322's phrasing also clearly refutes the same argument when made for Reply-To. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: Unfortunately z= and especially l= are not used practically by senders because they create a risk. One could add an attachment containing malware to the message for instance. Indeed, we have to assume that the MUAs are broken in this respect. See Daniel Gillmor's posts on the problems MUAs have with indicating which parts of a message are signed MIME parts in the testing MUAs thread. The basic state of the art seems to be that MUAs can't handle anything safely except a signature that applies to the whole message. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: When a list goes bad, usually the members are not blamed but the list admin, therefore making the list the system responsible of the writing of the message. Please stop being evasive. The RFC's use of responsible is intended to point to the person who wanted the content of the message injected into the email system. You know that, I know that, and you're just looking for an excuse to let your patch escape from its responsibility for undermining the standards on which electronic mail is founded. Anyhow, it does not matter, this is a religious discussion. Religious maybe, but it does matter. Open source lives and dies by open standards. Microsoft can (and does) get away with ignoring standards if they think that will enable them to destroy the competition by making non-Microsoft software inable to interoperate with Microsoft's. (Consider the number of complaints we get about Outlook's brain-damaged handling of the Sender field.) Let's *not* do it to ourselves *if we can avoid it*. Maybe we can't avoid it, but we really ought to try. Please feel free to code and test your solution of encapsulating the message in a mime rfc822. This seems an interesting and good alternative. I'd like to see it in practice so we can compare data. Without funding, I probably can't do it soon. My GSoC student Abhilash might be willing to do it after GSoC though. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: I'm not sure if DKIM was ever meant to be exposed to the end user, but the current trend is to try to protect the end user as much as possible and this is done best by MTAs than MUAs. I disagree fundamentally. It's best done by *both* MTAs and MUAs. Not all threats attack you from the outside, nor can MTAs stop everything that comes at them without help. That's why mail services provide spam folders to quarantine suspect mail. I agree that altogether too many MUA authors agree with you, so we can't expect much good to happen if we try to do things that depend on capable MUAs. That doesn't mean we shouldn't lobby for better MUAs. MUAs have the advantage of interacting with the user, and they can take advantage of the user's knowledge and intuition. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: I think, it is risky to code this encapsulation method directly and now, it requires a branch some testing and then merging back into the main branch. First, the risk is zero, except to volunteers, as long as it's not default. Second, it's been tested for decades. A MIME digest is nothing but one or more encapsulated message/rfc822 parts. In multipart/digest form, it has an obvious defect of requiring an extra click for readers using the MUAs I refuse to use (the MUAs I use can be taught to explode digests automatically, or read them as mini-folders). It would be nice to find alternative ways to accomplish the same goals, but this is already proof of concept. Third, it has the advantage of preserving as much or as little of the original message as the list would like without interfering with DKIM validation of the encapsulation. The author_is_list has had deployment and testing for over a year in a DMARC environment. Limited testing I agree but nevertheless proved Limited testing is not proof that something works. Limited testing can only *prove* that something is *broken*. More extensive testing is still not *proof*, but it can give you confidence that it's not *too* broken. Here is a recent test, deployment and analysis: http://sys4.de/en/blog/2013/08/11/mailman-dmarc-konform-betreiben/ I don't read German, but I don't see anything that looks like data, nor is there room for analysis. Nor does the blog by Patrick Koettner referenced therein. (The Google translations confirm that.) Please show us something that looks like data and analysis. Specifically of interest: Number of lists, number of users on each list (min, mean, max would do), duration of operation in this mode, type of users (mail admins vs. general technical vs non-technical), the MUAs in use, any discussion from the users themselves. I'd like to see somebody operating a mailing list with this encapsulation method first, before merging. Any list with MIME digests enabled and in use is a test of the basic usability. Do so on a site with DKIM-signing and you're done. All my proposal does is tune the encapsulation a bit. It might or might not work. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Mark Sapiro writes: I have had another thought. I will look at provisionally making ALLOW_AUTHOR_IS_LIST a 3 way switch for 2.1.16 with 0 or False (No) meaning current (2.1.15) behavior, 1 or True (Yes) meaning the 2.1.16rc1 behavior and 2 meaning the encapsulated message behavior. If you do, please change the name to DKIM_CONFORMANCE_METHOD or similar. But I don't think this is a very good API, because AUTHOR_IS_LIST[1] and DKIM_ARMOR (= encapsulate messages) are independent. Of course if encapsulation is used, there's very little point in rewriting From. But it doesn't interfere with doing so. Footnotes: [1] Barf - can we name this something that isn't a lie, like LIST_REWRITES_FROM, or better LIST_HIJACKS_FROM to distinguish it from the behavior of anonymous lists? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC Final report
Abhilash Raj writes: P.S.: There is a working version of my copy of mailman here[1] if you want to have a look. [1]: http://maxking.emoir.co.in A request: Abhilash is busy with exams for the next several days, so please post questions about the implementation to mailman-developers (strongly preferred) or write to me. I'll answer as best I can until he can come back online. I believe you can sign up for his list using Mozilla Persona. If you can't or won't (for whatever reason), I have an installation at mailto:maxking-t...@turnbull.sk.tsukuba.ac.jp and http://turnbull.sk.tsukuba.ac.jp/postorius and I can sign you up by hand. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Exim4 support for Mailman 3
Hi all, I have successfully added Exim 4 support to Mailman 3. The branch is here: lp:~stephen-xemacs/mailman/exim4 There's an instance at maxking-t...@turnbull.sk.tsukuba.ac.jp which also contains Abhilash's signed-list feature. Since it's very strict about checking signatures, it probably won't be much fun to use. :-P Postorius is running at http://turnbull.sk.tsukuba.ac.jp/postorius It's a separate process group from my main site, so the URLs you'll see in the address bar aren't very pretty, it needs the extra postorius in front to distinguish the top page, and I haven't bothered to fix the rest of the name space. No HyperKitty yet, sorry. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Murray S. Kucherawy writes: I wonder how long we can hold out before we start trying to drag [the MUA developers] into our conversations, which might be the only way to solve these pain points long term. It seems to me that Gmail, Yahoo Mail, Thunderbird, etc., must have either a team or an individual that spends time thinking about and testing user-visible solutions to these problems, so perhaps it's time to start asking them for help. To be honest, I don't think they really care. Even larsi, who never saw an internet-draft he wouldn't implement, is not terribly systematic about it -- as long as things are smooth between Gnus users, well, tough luck for the rest of the world. When I was talking to MUA developers about best practices for dealing with reply-to-list the basic response was we already have a function for that or sounds great, patches welcome. The Mozilla people were clearly much more interested in features like calendars and vcards. I think it's important we get started on it (and maybe I can contribute something now that GSoC is almost over), but I don't have much hope that the MUA developers will put a high priority on it. It's not really in their purview (see Franck Martin's comments about MUA irrelevance in this thread, for example, and he's not even an MUA developer). And of course the worst offender is Microsoft, which AFAICS is somewhat actively undermining the RFC 822 standard for reasons I don't understand. Regards, ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman 3 vs Groupserver vs Sympa
Hi, Kẏra! Thank you for your interest in Mailman 3! I'm sure I speak for all the developers in saying that we are honored! That said, what follows is the well-informed (I believe ;-) but individual opinion of one developer, complicated by the fact that Mailman development is quite decentralized because the web admin and archive management interfaces have been hived off into separate projects, as Nico points out. I'm not sure everybody will be pleased by my next few remarks, either. If Groupserver meets all your requirements and is stable, I'd have to say that's the odds-on favorite. Mailman 3 core (the user and list database manager, and mail delivery server) is in late beta at this point, and very usable. A few sites are using it in production, though I have no idea how mission-critical those lists are. However, the web interfaces (Postorius for admin and HyperKitty for archives) are still in flux, and recent development activity in Mailman core has been more focused on security issues (verification and re-signing of digitally-signed posts, refactored REST interface to improve authentication). Finally, Mailman 3 is still really about *mail*. It's not web-centric, although web access is dramatically improved where the features have been implemented. All that said, Barry still openly admits he wants Mailman 3 to kill web fora and secretly hankers after Linux-style World Domination. It might be worth waiting for. :-) Also, regarding the state of Postorius and HyperKitty you should definitely contact their developers. Most of them do hang out here on mailman-developers, but there hasn't been a lot of traffic about progress recently. I suppose they have their own channels of communication. You wrote: Are posts and administration integrated into the web interface? There is a Messaging Interface (aka MI) being developed by the Systers (as an alternative to Postorius/Hyperkitty) which provides some administration features, access to the archives, and reading and posting support. It is clearly intended to be used internally to an organization rather than as a way to support Mailman's traditional constituency of open subscription, (nearly) open post public lists. (Of course Mailman has been adapted to other kinds of lists such as anonymized lists, fully personalized lists, and announce lists, but it typically needs a lot of external support for applications like CRM.) Can you specify a posting rate restriction? What do you mean? (Presently the answer is no, but if you mean preventing users from posting more than N times in a day or something like that it would be easy to add.) Is full css customization for the web interface supported? Is css customization for the email interface supported? Again, what do you mean by this? Of course you can substitute your own CSS for that distributed by Postorius or HyperKitty in the web interfaces. There is no CSS in the email interface AIUI -- the email interface is whatever email program the user has chosen. I'm pretty sure that's not the question you're asking, though. ?? Is there site-side logging? (as opposed to server side) What do you mean by site and server? Sites have to be served. Is there a link to the post in the web interface in the footer of messages? If you want one and are using an archive manager that supports it, it's customizable. (I believe HyperKitty does support that.) The Systers' MI assumes a web-based interface, so no link needed. Now that users are more than just email addresses, can you request to contact a list member? Not implemented as far as I know. It would be easy to implement. Can users have multiple email addresses? Yes. Are there profile pages where you can see a summary of their latest posts? Not as far as I know, although HyperKitty could easily provide something like it, if not already implemented. Note that unlike LinkedIn (for one example) where there's a single profile page and the owner get an edit interface while 3rd parties get a read-only view, HyperKitty and Postorius will have different viewpoints about the user profiles (although HyperKitty can probably access the same information that Postorius does via Mailman core's REST interface). The Systers MI probably provides a more unified view, but it's pretty alpha at the moment, and Systers-specific. Are usage statistics provided? Not by Mailman itself. They are easy to provide by trawling the logs (the Mailman 2 approach). In Mailman 3 they could be kept internally and made available by the admin interface to HyperKitty or Postorius if we knew what statistics are desired. What do you want to see? Also, did Mailman 2 already support LMTP and virtual domains or are those new? LMTP, no, although I believe it was possible to fake it by talking LMTP to Mailman 2's incoming SMTP interface (they're nearly the same protocol). Mailman 3 *only* supports LMTP for incoming posts, delegating the hairy interaction
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Patrick Ben Koetter writes: Maybe documentation that tells interested people how they can start using the beta? I'm not sure what you mean. None of the GSoC students had trouble with getting Mailman 3 itself up and running once they got it checked out and installed. From that point of view, the documentation in the Mailman checkout seems sufficient. And we now have two of the three most popular MTAs covered (Postfix and Exim). Installation from source is currently somewhat painful, indeed, but I don't think poor documentation is the problem. Anyway, good packaging solves the installation problem. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Terri Oda writes: But yeah, I think packaging [the suite] well (and then documenting *that*) makes a lot more sense, +1 unless someone's feeling particularly inspired? -10 -- it's all gonna turn upside down when we package, anyway. [Aside: If you're feeling *that* inspired, volunteer for Google Code-In, CopyleftGames.org -- Arc sez we gonna need a lotta help!] Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Ralf Hildebrandt writes: Absolutely. Topics of interest to me would include: * what has changed (GUI?) Already in the beta distribution. But briefly, everything's all-new, all-shiny. There will be mailman2-to-mailman3 migration scripts, of course, but the admin and archive websites are completely new. They are functionally similar so will seem somewhat familiar, of course, and where possible Postorius maintains a similar layout, I think. Where else do you expect to find this information, so we can put it there? * how can I install mm2 and mm3 side by side (if possible at all, I'd like to be able to switch back an forth if the shit hits the fan) Uh, just do it? Of course it will be MTA-specific. I haven't done it on Postfix, but for Exim you just add a Mailman3 router and transport ahead of the Mailman2 router (I've already submitted the docs for that -- they're very generic -- don't know if Barry's merged them yet), and start adding Mailman3 lists. To reverse migrate, make sure the relevant is this a mailman3 list config file is moved out of the way if you want to switch a migrated list back to Mailman2. For Postfix, I suppose you have to mess with the aliases directly. Caveats: (1) I have no idea about importing archives from HyperKitty into Mailman2. (2) Reverse migration preserving configuration will not be trivial -- you'll have to keep the original configs around for lists that migrate from Mailman2 to Mailman3, and make new ones for lists newly created on Mailman3. We could make scripts for (2), but I wouldn't trust them very much, they're not going to get a lot of testing. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Ralf Hildebrandt writes:
Where else do you expect to find this information, so we can put it
there?
I must admin I haven't tried installing yet, mainly because I didn't
know how to go back in case of problems.
Repeating what I already wrote for completeness here: Migrating and
then going back all at once is not necessary. You can migrate bit by
bit, although it may require a little bit of manual fiddling if you
get to the point of installing both on a production server. By
little bit I mean installing in {/usr,/var}/lib/mailman3 instead of
{/usr,/var}/lib/mailman where Mailman 2 probably lives.
I have to admit I haven't installed into one of the standard
hierarchies yet; I run my Mailman 3 lists (all test or
non-mission-critical) out of a Python virtualenv in my home directory.
Re installing betas from source:
I wish I could say, oh, just try it, you'll like it, but building
from source isn't as automatic as I'd like. It's not a huge extra
effort (ask here), and I have had it install (a few commits back) with
just bzr clone ...; python bootstrap.py. I just prefer a reliable,
completely turnkey package when recommending to pure beta testers,
and it's not quite that yet.
If you do try it, be warned that a couple of tests may infloop (for
reasons unknown), although only under some circumstances.
Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Aurélien Bompard writes: I don't recall, but I think finishing HyperKitty was one of them. AFAIK it doesn't work as advertised now (at least that's what Shanu told me in her work on a unified Messaging Interface for Systers). Oh, I'm interested by any bug reports. Please. I don't recall precisely what the issues with running HyperKitty were (she tried installing from source once in March, and again in June). What killed the deal for her was an inability to get existing archives imported due to inadequate documentation. I eventually figured out how to get that done, but by then I just advised her to use the trivial archiver from the core. It looks like the documentation has improved (but I haven't actually tried following it yet). And for all of HyperKitty, there were over 1000 lines of changes since March, and and it looks like over 500 since June. I guess I'll have to try it again before trying to report bugs. For the record I'm currently setting up HyperKitty Postorius in the same Django instance, it seems to work fine (didn't test single sign-on yet but I will). It would be nice if you at least reported releases here occasionally. According to news.rst there have been two releases since PyCon (1.4 and 1.5), and there is a 1.6 tag in git. I've also created a branch and a pull request in Launchpad with lots of modifications to the import script. Branch and pull request for what import script? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Aurélien Bompard writes: Branch and pull request for what import script? The import21 command, which is meant to import an existing 2.1 pickle configuration file into Mailman 3 Ah, now I see. I thought you were still talking about importing archives. Thank you very much for this work! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Barry Warsaw writes: So this feature in particular, if Postorius can do all the necessary confirmations, I can much more easily provide an API that Postorius can call to associate an email address with a given user. I'm getting that ol' sinking feeling. Either Postorius is *the* Mailman 3 user/admin UI, or it isn't. If it is, shouldn't we merge the projects sooner rather than later? If it isn't, Mailman should be able to do this kind of thing itself. It should be reasonably low-cost to build a simple django app (or lower-level, SimpleHTTPServera app) that handles confirmation. Or we can do without web confirmation URLs if there's no admin UI available. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Barry Warsaw writes: Mailman2 router (I've already submitted the docs for that -- they're very generic -- don't know if Barry's merged them yet), and start adding Mailman3 lists. This branch? https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j Yes, but don't worry about it. It's straightforward and I'm happy to support Exim users who want to try Mailman 3 (don't post all at once, now...). Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] REST API call for creating archive view?
Colin Fleming writes: Is there a way to create an archive view (i.e. present a view of all messages in a list and allow reading particular mails) using the current API? No, and (sorry Barry, but I think you just added to the confusion -- IArchiver is really a write-only API) there won't be unless the architecture of Mailman 3 changes dramatically. Archiving (storage and retrieval of posted messages) is the responsibility of a separate module. What Mailman itself can tell you is the suggested permalink for individual archived messages. We do plan to provide such a module (the current implementation and leading candidate is called HyperKitty). I do not know if the current architecture of HyperKitty is sufficiently modular as to allow you to just grab messages and then format them yourself. I'm not sure why you'd want to grab raw messages, actually; I think the best idea would for HyperKitty core (or any other implementation of an archiver) to spit out a DIV element containing the (semantically) formatted email message, and provide a default CSS, plus a fairly trivial full webapp that wraps the DIV in a full page. I'm not sure if it does that yet, though, you need to talk to the HyperKitty devs about it. (Heck, if it doesn't, maybe I'll go into the archiver business myself. Look for CSSZenKitty at a DVCS host near you!) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman DMARC Support (it's not what you think!)
Franck Martin writes: As they say at IETF: Read the spec! :P I have (probably three times carefully by now), and I still can't understand why you think DMARC makes any sense at all for mailing lists. (I have no trouble at all understanding why Citibank thinks it's great. But that's a completely different use-case.) It might help if you gave us the annotated version of what you do like about it, instead of telling us that everything we've been doing for 20 years is wrong, and that we're crazy to object to the violation of the most fundamental and ancient email RFC (not to mention violating copyright law in every Berne Convention signatory) by corrupting the authorship information of each post we process. As Jim says, the only real hope mailing lists have is some kind of digital signature protocol that allows the list to testify to having performed its own authenticity checks before forwarding the post. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Adam McGreggor writes: https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j 404s for me; is http://bazaar.launchpad.net/~stephen-xemacs/mailman/exim4/revision/7219 the same? Yes, that's the one. it might be worth adding a reminder that order of routers matters in Exim (or perhaps add that to the note: I mention that in Troubleshooting. Maybe I should change the section name to attract the eye of those not yet in trouble? I dislike writing the same thing multiple times, and especially duplicating manuals in code. It's a maintenance burden (slight, but it adds up if done a lot), and it also sometime makes me wonder if I actually saw something when I find a section of text where it should be included but it's not there. Then it turns out a more accurate discription was somewhere else -- rgh! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] REST API call for creating archive view?
Colin Fleming writes: Thanks for the comments, Steve - can you clarify what you mean by a write-only API? Mailman core has no way to retrieve those messages. For the rest, I think Barry's answer is clear and definitive. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
Ian Eiloart writes: On 30 Oct 2013, at 13:33, Stephen J. Turnbull step...@xemacs.org wrote: Repeating what I already wrote for completeness here: Migrating and then going back all at once is not necessary. You can migrate bit by bit, although it may require a little bit of manual fiddling if you get to the point of installing both on a production server. The tricky bit here is the continuity of the web interfaces. If a list manager is used to going to lists.example.com/Mailman/listname, and they have that bookmarked, then they’ll want to keep going to that same place. Sure, and I don't blame them. I could have been more careful in expressing myself. I didn't really mean that you could do it in dribs and drabs, rather that you could start with a test list that the kind of beta tester who uses git to get betas wouldn't mind being on, move on up to a few hard-core techie lists whose members understand beta, and only when people are satisfied that those are working, then do the rest. And at each stage it's reversible without losing data -- but not necessarily at zero cost to users, or to you. Whether that's good enough for you is something you'll have to decide. I just wanted to make it clear that if you *had* a working Mailman 2 installation you can revert to it. I’m also nervous about breaking migration through the archives. Unfortunately I don't know enough about HyperKitty to help you there. I suspect that the HyperKitty guys have paid about the same amount of attention to consistency across migration as the Postorius folks have, and it matters more there because who knows what people might have bookmarked? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PGP-signed message verification using the email module (and in Mailman)
Daniel Kahn Gillmor writes: so if python's email module really does mangle this part, it cannot be used within RFC-2480-compliant mail gateways. This is a bug in python's email module, and it needs to be fixed. Have you reported it to the python email module? I believe the problem is known, and in any case the problem of header munging in general is known. I don't have a ticket number off-hand though. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3: Problem with binding REST server to custom address
Barry Warsaw writes: the address 0.0.0.0 to access it from outside of the VirtualBox with Port Mapping. 0.0.0.0 is a reserved IPv4 address: http://en.wikipedia.org/wiki/Reserved_IP_addresses#Reserved_IPv4_addresses I don't think it's a very interesting idea to bind a listener to that address, since it could only hear broadcasts. *shiver* But for exactly that reason it's often used as a non-address token to express that the network server should to bind to all available interfaces. I tried with a custom settings file 'mailman.cfg' in my Mailman working directory in which I set the property hostname to 0.0.0.0. Now when I call 'mailman info' it shows the custom defined hostname in line starting with 'REST root url' but I can't access the API from outside the virtual machine and the command 'netstat -lntpu' displays that the REST server process was bound to the address 127.0.0.1 and therefore is of course only accessible from localhost. Given the above interpretation, it looks to me like your problem may be that the only interface found has address 127.0.0.1. I don't know much about VirtualBox, but I would look at its configuration and that of your webserver (WSGI is not a webserver, it is an interface between Python and a real webserver), despite your simple experiment (which is far from eliminating configuration errors based on the data you've provided so far, although it might do so based on information you haven't given us). ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3: Problem with binding REST server to custom address
Barry Warsaw writes: On Feb 04, 2014, at 02:49 PM, Stephen J. Turnbull wrote: (WSGI is not a webserver, it is an interface between Python and a real webserver) Right, but the wsgiref stdlib module does provide a WSGI-compliant HTTP server, which is what Mailman's REST runner uses currently. Indeed, but my point is that unless the full configuration that Mailman uses and the full configuration for the OP's simple HTTP server, not to mention the exact test case run with the simple HTTP server are specified, we can't be sure it's a Mailman problem. AFAICS that point stands. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 ideas list
Hi, Máirín! Good to see you here! Máirín Duffy writes: Do you know if Summer of Code students can do interaction design / UX stuff? Because I'd be willing to mentor for that. I'm not sure what you mean by design. Something like graphic design via CSS alone doesn't fly. It has to come with an implementation that is aimed to be of high enough quality to be integrated. If the project misses implementation quality by end of summer, nobody's going to complain if we pass the student based on reasonable effort and significant progress. But what Google is paying for is the time and effort spent on designing and writing code to implement processes, not the UX design. Eg, doing CSS work that makes a screen pretty and easy to hide uninteresting information and changes simple text fields to more structured widgets (eg for date input) is out. Writing JavaScript that sanity-checks user input is OK. If what you mean is the kind of stuff that is involved in Postorius and Shanu Salunke's Mailman Interface (a GSoC project for Systers last year), yes, that passes muster. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 ideas list
Máirín Duffy writes: By UX design I don't mean simply surface aesthetics, but designing the interactions and workflows for new features and cleaning up what's there, scoping out new features (e.g., right now Karen and I are working out whether or not users should be able to follow categories in Hyperkitty like they can follow tags, walking through what a user might want to do based on how mailing lists may be set up, and the mechanisms we could add to allow the feature.) The implementation of workflows such as following categories like tags and mechanisms sounds good to me. New features are generally what Google is interested in sponsoring. So she is doing some CSS yeah, but also javascript and she's modifying stuff in django too for the Bootstrap upgrade. AIUI, the javascript and Django work sounds like it would be enough to qualify for the Code in Google Summer of Code. Testing how well it works across various mobile formats. Testing in the sense of running the program on different devices doesn't qualify, and ISTR discussion on the Google lists to the effect that even writing regression tests doesn't qualify by itself if they basically amount to scripts to mimic a human thumbing on an iPhone. :-) There's also a prejudice against declarative languages like HTML and CSS.[1] Google recognizes the value of CSS and regression tests, of course. There has been discussion of extending GSoC (eg, Google Code-In for high school students allows tasks defined by those activities, and documentation as well), or having a separate intern program for them. But GSoC is designed and funded for the purpose of supporting coding. So from the point of view of GSoC proposals, the students should be focusing on the Javascript and Python to be written to implement the features in Django. Overall it sounds to me like the project your student would propose is very similar in content to what Shanu did, and the main thing is to emphasize the Django/Python and Javascript coding, and make sure it looks like a summer's worth of work in the proposal. I would say at this point it's certainly worth writing up a preliminary design proposal to see if it's worth putting in the work to write up schedules and precise descriptions of deliverables. Also, note that I can't speak *for* the Google administrators. Footnotes: [1] I mention that because I find these distinctions somewhat specious, myself, but the language bias clearly exists among the Google administrators. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Fwd: Google Summer of Code 2014 FAQs
Zeel Shah writes: I want to request any mentor out there please throw some light about these two projects. We're still in the application process. You're probably not going to get a lot of love from mentors until after the 24th, when Google announces the accepted orgs, or perhaps later if we need to negotiate with an umbrella org such as the Python Software Foundation. So please be patient. Personally I can't give you a lot of encouragement. I'm interested in the core, and especially in authn/authz/signature/encryption issues, not so much Postorius. And I don't know anything about Android (or iOS for that matter) development. So I'm not a likely candidate to mentor those projects. During installing mailman in my laptop as described in following link ( http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running) in the following step: (postorius)$ cd mailman (postorius)$ python setup.py install (postorius)$ bin/buildout (postorius)$ bin/test I am not able to go ahead from the third step. Which is as follows: $ bin/buildout bash: bin/buildout: No such file or directory Didn't your university teach not to trust anything you read on the 'net? ;-) Mailman 3 (core) has transitioned away from buildout, and now uses setup.py only. Look for instructions in src/mailman/docs/START.rst. Good luck! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Implemented Mass Subscription via file upload
Rajeev S writes: I have implemented a mass subscription via file upload feature for Postorious which can be found here. https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk How am I to submit a merge request to the Postorious repository?I tried to propose a merge via the launchpad, but says the branch cannot be merged. Postorius is an entirely separate project as far as Launchpad is concerned. Your URL suggests you derived from mailman, in which case Postorius and Mailman share no ancestors and the merge has to fail. If that's not it, I'll try to check the actual code later. :-) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014
Barry Warsaw writes: On Feb 24, 2014, at 09:54 PM, Florian Fuchs wrote: The good news: The Python Software Foundation was more successful (congrats to Terri!), so we'll be able to participate under their umbrella again. \o/ Much thanks to Terri and all involved. Looking forward to some great GSoC students again this year. Yes, many thanks to Florian and Terri! @Florian, Terri: is there going to be a why some orgs get in and some don't session again this year? (Sorry, I've had no time at all to follow the process this year. :-( ) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [Mailman-Users] MM3 Test Hangs
Tom Browder writes: We really appreciate your efforts to test the betas of Mailman 3. But please do be aware that although there are sites already successfully using Mailman 3 in production, the development team doesn't recommend use of any of the components (core, Postorius, HyperKitty) in production yet. I have no idea what to do next, Nothing. :-) I've already Cc'd (and set Reply-To to) mailman-developers, which is a more appropriate place for this report. (Many Mailman-Users are not interested in MM3 yet, while Mailman-Developers are by definition, as MM2 is basically end-of-life. Also, some relevant developers may read mailman-developers more frequently than they read mailman-users.) Actually, I do have a couple of ideas. First, you should always report the whole error trace (if you think that's ugly in an email, attach it as a file). In this particular case, I suspect that the problem is in the test before the one that caused the Exception, which failed leaving the database locked. It would be very helpful to identify that test, which would probably be the *first* frame in the trace. Second, you should look in the server's logs to see if there were any errors that might have caused the incomplete transaction. and help or ideas would be greatly appreciated. If you have no idea, then reporting to the developers is the best you can do. Use Mailman Developers mailman-developers@python.org or report via Launchpad. Pretty clearly what's happened is that some previous test locked the database (probably anything that accesses the database does so at least long enough to read the whole record), and either (1) that test failed to unlock the database, (2) the test framework failed to unlock the database, or (3) the tests were improperly sequenced in some way and the database didn't get unlocked. It's quite possible that this failure could never be replicated in actual use, as tests often mock up some component that would normally ensure that any pending transaction gets discarded and the database unlocked. Unfortunately I don't have an up-to-date test installation (it's on my list for early next week), and looking at the test file doesn't tell me anything. Perhaps Barry has an idea for a fix, or a workaround. And there's probably a way to skip that test, but I don't know nose very well. Steve Original report follows: i have started investigating MM3 for my new, remote server and branched from lp:mailman, lp:postorius, and lp:hyperkitty. I started in the MM3 branch directory and followed instructions in src/mailman/docs/START.rst. I got the virtualenv ready to go and, in the local mailman branch directory, I executed: $ node2 -v All tests chug along nicely until: /usr/local/src/0-mailman3/src/mailman/rest/docs/membership.rst ... and it hangs longer than I think it should. After a ctl-C the last few trace-back lines are: File /home/virtualenvs/mm3/local/lib/python2.7/site-packages/storm-0.20-py2.7-linux-i686.egg/storm/database.py, line 374, in raw_execute self._run_execution(raw_cursor, args, params, statement) File /home/virtualenvs/mm3/local/lib/python2.7/site-packages/storm-0.20-py2.7-linux-i686.egg/storm/database.py, line 388, in _run_execution self._check_disconnect(raw_cursor.execute, *args) File /home/virtualenvs/mm3/local/lib/python2.7/site-packages/storm-0.20-py2.7-linux-i686.egg/storm/database.py, line 454, in _check_disconnect return function(*args, **kwargs) sqlite3.OperationalError: database is locked Note I am running the MM3 installation, via ssh, on a remote host running Debian 7, 32-bit. (Note also postfix is running.) ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test Hangs
Nicolas Karageuzian writes: I encountered db lock using sqlite with mailman3 and tools. Switching to postgres avoid the db locking states. Maybe you should explore that way. Hyperkitty moved to github so the lp ref is quite out of date for this resource. Thanks for the advice! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [GSOC 2014]Approach towards the Full anonymization project
Rajeev S writes: As mentioned, here is my approach towards the full anonymization project. AFAICS as far as described it will provide the outcomes you describe. However, I don't understand the use case here. Most approaches use a single secret ID for each user. This is not just a matter of convenience for the developer, but a requirement in some cases. That is, the list members, although anonymous in the real world, build trust relationships with each other in the list environment. Full anonymity is in any case difficult to achieve, as word choice, topic choice, grammatical construction, time of writing, etc fall into patterns over time. Also, given your model of address-per-post, I'm again unclear on the use-case for off-list communication via the list server. Finally, there are a number of sets of details you don't mention here but need to be discussed in your plan (even if you don't propose to implement them now, you need to ensure that you don't make it difficult to implement them!) First, there's a question of how the proposed off-list messaging is going to be handled. Those pseudo- random addresses are going to need to be made valid addresses to the host's MTA. That's MTA-dependent, and also will likely have security implications. To be sure that people don't inadvertantly reveal their identities just by hitting R those messages should be anonymized as well, so that any such replies have to go through the server too. Of course it's going to be impossible to prevent people from exchanging email addresses in the body of the text, but in that case it's really not your problem any more. The second is cleaning up the rest of a post. The incoming trace headers typically identify the sender quite precisely. Quite likely you'll want to nuke everything that isn't required by the RFCs, in fact. You probably also should try to do something about .sigs, Message-ID (which is required), Date (also required, and which often gives timezone information) and other automatically added text. Third, what about authentication for incoming posts? Do you care if people spoof addresses? I'm not sure this has any meaning in the one-shot address environment you propose, but that again is going to depend on the use case. Fourth, you need to think about security for the encryption key and EmailMapper table, as well as any archives (you need to clean up archived posts before they go to the archive -- this is probably just a matter of where your Handler goes in the pipeline). - Introduce a new model EmailMapper with attributes - ForeginKey to Address / User - seed, A 40 bit hash,unique - nuses, number of times this hash is used,max 5 or 10 - The approach is to encrypt the seed nuses times, with encryption algorithms like AES, each time the email ID is displayed. - The email ID is displayed as nusesencrypted seed - The email is decrypted nuses times to find the parent seed and thereby point to the exact email address. - A new seed should be generated for the user after a fixed number of attempts,say 5 or 10,as the repeated encryption routines can slow down the system. The outcomes - Everytime the user sends a message,his from address changes. - At the same time, each of the from addresses point to the same user. - The sender can use any stored address he has,like in the mail contacts,repeatedly, to contact with a user,as it has nuses attached with it. So you need to store the addresses forever. How big might these tables grow? Could that be a problem? Did you consider using the seed as a salt instead? Ie, regenerating the seed each time, adjoining it to the address, and encrypting the combination? That would allow you not store a database of addresses. Of course if the encryption were compromised, all the old posts could be identified, whereas in your scheme the EmailMapper table also needs to be compromised to get addresses. Regards, and good luck with your proposal! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Gsoc idea discussions : Continuous integration tool
varun sharma writes: Why would you use Django to build the tool as opposed to just a python package? I was thinking of expanding it like buildbot to include django based GUI and detailed reports. So i thought we can use django, but if we just want a command line tool, then python module will be fine. Why not do both? I think that you should be able to separate the business logic from the UI elements. Then use the if __name__ == '__main__': technique to implement the CLI, and import the module into the optional Django front end. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Wiki edits for GSoC 2014
hi guys, I just added a link from Sprints to the GSoC 2014 page. I have found it frustrating to see queries from interested students about projects where I have no clue who the appropriate mentor might be, and haven't seen any responses on-list. So ... I took the liberty of adding a Potential Mentors line to each project description, and adding myself to several of them. The rest currently say to post here. I also noticed that the Handheld App didn't have a Task Level, so I added it (as unspecified). I'm sure the currently signed-up mentors know what to do :-), but if you're considering being a mentor for any of those projects, please do add your name to the project on the wiki. At the very least your input will be very valuable in finding an alternative. If you're pretty sure you are willing and have time to mentor, do go through the GSoC Melange process too. The more mentors we have signed up, the better we look to the PSF (although they've been quite generous to us in the past, every little bit helps -- intern slots are scarce!) Let's make this the best Mailman GSoC yet! Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mentor list on project page
Hi, I added a Mentor List (ie, roster) at the end of the project page, and added (besides myself) Florian, Barry and Terri. I don't mind having my address there (so added it) but didn't take liberties with anybody else's mailbox. Regards ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Command line Client
Rajeev S writes: The deliverables of the project would be, at the least, - Command line tools to perform tasks in the mailman client docs I think there should be one tool with multiple commands. These can be implemented by separate commands in a directory off the normal PATH if you like, or with annoyingly long names (a la git's scripting interface). - Any Extra useful functionalities that can be identified, such as export, backup - Other Useful tools like backup and restore. - Man Page entries for the new commands These look good to me. Also, a help command to display the man pages from the new tool. Also, I did not quite get the *coming up with a **great layout * part. Do you mean to build a custom shell for mailman? If yes, what extra functionality should it provide than the standard command line tools? I think that probably is what he means, but I personally don't think that's appropriate. If people want a CLI with layout (which I agree is plausible), what's wrong with Postorius via Lynx? (Florian?) I suggest you should concentrate on the syntax of the command line, possibly building on the existing mailmanctl tool. (But let's check with Barry on that before you put in much effort!) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mentor list on project page
Abhilash Raj writes: Hi,I have a pretty good understand of the mailman core, I would love to co-mentor any project if I am allowed? You're allowed. Lots of former students (and the occasional current student as well!) are mentors. Some of the following my sound harsh, and it is my private opinion; I don't speak for Mailman or for GSoC. I expose it on this list because there may be others lurking with the ambition to be a mentor, and they're in similar situation to you in many ways. I'm not opposed making you a formal mentor (that's not my decision, but my opinion will surely be input to it), but I'm not very positive right now. I have had only very sporadic contact with you since GSoC last year. No explanations needed, it's just a fact, and it's two- sided issue, anyway. I just want you to know where you stand -- it is not a criticism of *you*, and it's not a decision. To be a formal mentor (and get the stupid T-shirt :-), you will need to establish a presence with at least one, preferably several of the current mentors. We need confidence that you'll be available to the student when she/he gets in trouble. Not 100%, but a mentor or co-mentor who doesn't contribute much and then disappears halfway is a really bad thing, and we especially need confidence that you'll be around at deadline time (there's no administrative difference between mentor and co-mentor: both can edit the evaluation forms, both can see the same student data), because you may need to do the evaluation if your co-mentor is unavailable. On the other hand, informally, if you want to mentor, just start. wink/ Your goal should be to make it clear that we can't dispense with your advice on a project we want to implement. Then we *have* to make you an official mentor! (I'm not sure if there's a deadline on that.) Of course indispensible is a *very* high standard, but the advice to just start mentoring (on-list) is the best you're going to get. The more of that you do, the better we know you. Including your faults -- having your faults known IS AN ADVANTAGE because that way we can give you a good teammate who has strengths there! Other things you can do: participate in the sprints at PyCon. Most of the mentors will be sprinting. I can't go myself, but will participate by IRC and email, and try to do work in advance so it's easily available to the onsite sprinters. Of course general development work, submitting patches, and discussing them publicly is useful. But in the end, the most effective path is to show that you *are* a mentor, by doing it! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Command line Client
Florian Fuchs writes: One is the one-off command (with options) that outputs a result, either on stdout or saved to a file. This could make for an interesting project, but I think then it would really make more sense (like Steve said) to extend the existing `mailman` command instead of writing a new one. Ah, I see. I think that what you're talking about, then, is deciding how much state to keep in configuration of the client, how much to require the user to enter, and whether to save state changes made during an interactive session. For stateless commands like status (it reports the state, but issuing it is the same regardless of current state), or simple state- dependence (a list lists on domain command might be mmclient list lists domain=python.org) you could do it as a shell command. For more complicated, state-dependent commands: $ mmclient mm status all qrunners running mm set domain python.org mm set list mailman-users mm list members from list.org ba...@list.org mm ;-) Then set of questions might be should mmclient automatically save the settings for 'domain' and 'list'? Or should there be a 'save current settings' command? Or a special 'configure settings' command? Or should the user edit mmclient.ini? Is that the kind of thing you mean by layout? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM 3 and Postfix + Apache
Barry Warsaw writes: BTW Tom, are you trying to run MM2 and MM3 concurrently? I'd like that to be a supported deployment use case, but haven't had much time to try it myself. I do this already, but with Exim4 as MTA. It's not hard. Of course if both installations have lists of the same name (including the domain part) one installation has to shadow the other for those lists. (I guess it would be possible to configure Exim routers list-by-list so that you can choose which takes precedence on a per-list basis, but it sounds like asking for trouble to me, and I haven't tried it.) ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM 3 and Postfix + Apache
Tom Browder writes: On Thu, Mar 6, 2014 at 1:36 PM, Stephen J. Turnbull step...@xemacs.org wrote: Barry Warsaw writes: BTW Tom, are you trying to run MM2 and MM3 concurrently? I'd like I do this already, but with Exim4 as MTA. It's not hard. Of course if both installations have lists of the same name (including the There will not be any identical names, so maybe doable fairly easily with Postfix? Yeah, I suppose so. I don't recall how Postfix does the dispatching. Exim basically has a chain of what it calls routers, which look at the message and metadata (the envelope addressee's mailbox is what I use), apply other tests (checking for the list's config pickle is what I use, but it would be possible to query a database or even call out to the Mailman3 REST API -- probably a bad idea, since if Mailman is down, the router will fail, but possible), and dispatch the message to a transport for delivery (piping to the Mailman program). Routers are first full match wins, so it's quite easy to understand the logic. In particular, a one host, multiple Mailman installations setup requires just one router per Mailman installation. The router's check for a file system object is what disambiguates the installations. Usually Postfix is configured to route mail with a set of sendmail- like aliases files, so you just define different alias files for each Mailman installation and configure Postfix to look at them with the alias_database directive in postfix/main.cf. I guess Mailman itself can be used to generate them without much trouble. What I can't help with on Postfix, and something I suspect Barry will be concerned with, is virtual domains where dom1 prefers the tried and true (Mailman2) and dom2 is ready to try something new (Mailman3). In Exim this is no harder; the routers just check for the virtual domain as well as the mailbox and config files. I don't know how Postfix would handle this; the alias files only know about mailboxes as far as I know. The virtual domains are sorted out by a different mechanism. Regards, Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Gsoc idea discussions : Continuous integration tool
varun sharma writes: Can i use buildbot for the server part and integrate it with frontend suite ? This is way too compact to understand what you're proposing. If you mean configure a buildbot to build and test Mailman 3, and that's it, no. This is Google Summer of *Code*, and you have to write a substantial piece of code. If we can't figure out what you're proposing, your proposal will not be adopted, no matter how much we want the feature. Please read http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt for some hints on how the proposal process works. Most of this is not yet applicable to your proposal, it's more about the completed proposal. But it will give you an idea of where you need to be headed. At this stage, you need to be clear about the *requirements* you propose to satisfy, so that we can evaluate your proposed *design*. These can be very rough (the sentence quoted above is about half of what you need for design *at this stage*; the other half is an explanation of what the frontend suite is and how they will be connected). But Continuous integration tool is not even close to specifying requirements. What is your tool going to do? Your full proposal will need to be more detailed -- we need to be able to estimate how much code you need to write, which means a fair amount of detail about the requirements, at least. We need a couple of intermediate milestones, so that we can evaluate your progress at midterm. We expect to be working with you over the next couple of weeks to refine your proposal. (Occasionally students deliver a full proposal out of the blue, but that's very rare.) I tested buildbot on postorius Again, I have no idea what you're trying to say here. Postorius is not a platform for running buildbot. What does this mean? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Gsoc idea discussions : Continuous integration tool
varun sharma writes: On Fri, Mar 7, 2014 at 7:14 AM, Stephen J. Turnbull step...@xemacs.orgwrote: [ long irrelevant quote snipped -- please trim! If you really can't trim because you're using a handheld in a crowded bus on a very bumpy road, please *top* post, but make sure your text includes enough context -- readers should not have to dig through a long quote to find the exact text you are responding to. ] Sorry, if i wasn't clear enough but from frontend suite i meant the command line interface that is going to check for the integrity before the commit (i.e mm_gatekeeper on developer's machine). OK. Why is this a CLI (command line interface)? Does it need to be controlled by hand? Isn't this going to be some sort of daemon triggered by commits to the trunk (or other watched branch)? Below you write python module -- if that's what you mean, it's a better way to express it. I was trying to say that: Is it possible if i write the command line interface myself by adding all the unit tests for all the projects to be involved in the integration suite and let buildbot handle the build testing part ? Yes. This is not only permissible, it's good design, and very desirable. The work that i am expecting to do in this project is: 1. Write a python module mm_gatekeeper that will handle all the integration tests for all the projects involved in the mailman suite on the developer machine before commit. OK. I'm not sure what you mean by integration tests. Also, as I understand it, usually continuous integration does not refer to integration of components with each other, but instead it means integration of new code into the public repository. Ie, although testing is part of it, it's really a workflow manager, not a test framework. If you're interested in integration testing of the components, that is not a problem, we can use that. But we should straighten out our terminology so everybody is expecting the same project. 2. Forking buildbot for adding build testing from the repository and tweaking the buildbot code to meet our requirements. Do this only if necessary, I think. We can discuss when you get to actual coding, of course. But 1. buildbot should be pretty flexible, enough to handle this task. 2. If you only need a little bit more, it might be better to wrap buildbot with extra capability rather than change it. 3. If you do need to change it, we will definitely ask that you try to get upstream to add the additional capabilities. I deployed buildbot with aws ec2 on postorius independently by adding repo of postorius_standalone at http://dev.sharmalabs.com:8010 and added the commands that are required to run the unit tests. OK, that looks pretty cool. I suggest you add the URL for your code repo to http://dev.sharmalabs.com:8010/about. All of your Internet facing sites should have an about or home page with links to all of the others. Do you have a blog? Sorry if you have already posted all that information. Remember that we have a lot of students, most of us participate in multiple lists which are currently swamped with GSoC students, and some of us mentor for more than one org (or are org admins, which also takes up a lot of time and energy -- thank you Terri!). Please humor us if we ask for your information more than once. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Gsoc idea discussions : Continuous integration tool
varun sharma writes: Actually my idea is to import all the unit tests from the projects involved in the suite and write new tests as well if required, so that we can check both integration of new code and integration of components with each other. Selectively combining unit tests of different projects will do the job of workflow manager ? No. Workflow is the process by which the project develops new code, and includes handling user requests, assembling requirements and specifications, designing features and fixes, implementing them in code, testing, reviewing, approving, pushing to the mainline repository, and releasing. The order above, when implemented over the whole release cycle, corresponds pretty closely to the infamous waterfall workflow, but most open source projects don't follow that. Integration generally refers to some subset of the testing, reviewing, approving, and pushing steps. It pretty much always includes the testing and pushing steps, because those are the sore point. Even when a developer is conscientious about testing before pushing, there is a big problem because in the time that you're testing, somebody else will push, and you have to pull and retest. Note that more test failures is not an issue, *somebody* will have a test failure if it's going to happen. It's the time spent testing if there *isn't* going to be a failure -- most of the time -- that we'd like to avoid. So continuous integration is a process that automatically queues merge requests, tests them, and pushes to mainline until a merge fails tests. At that point, the requested merge is rejected and the responsible developer needs to deal with it, but the integration process goes on to the next changeset in hopes that that one won't fail. That doesn't mean you have to *do* what I've defined as continuous integration, just that continuous integration is a bigger job than just buildbot for three projects at once. Just the buildbot project would be very useful. One warning: Google is very serious about *code*. Simply configuring a buildbot or three isn't going to qualify, you need to write substantial additional code. Do you have a blog? Yes, i do :) (http://www.sharmalabs.com).Right now i don't post actively on it but I'll be posting weekly gsoc summaries there if i got selected. :) Up to you, but starting now is helpful to your chances ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Getting mentor attention [was: Mailman SNMP support]
Nitin Agarwal writes: Here its Nitin Agarwal, an open source Software developer and enthusiast. Hi, pleased to meet you. I'm belatedly replying to the list, and at length, as there are other students in your situation. I hope it helps. First off, I saw you talked to Terri on IRC. Much as I hate to burden Terri, that is the right thing to do if you're not getting attention to your proposal, especially from persons who proposed or volunteered to mentor it. If at all possible, try to grab GSoC people on IRC (or by email) in the following order: 1. Any other mentor or active developer, to get comments first. 2. Barry. 3. Terri or Florian. 4. Jessica (real last resort). Contact info for the above is on the Ideas page. Barry isn't official in GSoC, but he's head of the Mailman project and a ranking demi-god in the Pytheon. Also crazy busy, so you may get a polite brushoff. OTOH, he can probably solve Mailman problems in half the time of anybody else. And if Barry asks for help, someone will respond. Terri and Florian are PSF org admins, not just Mailman IIUC. Crazy busy, too, but dealing with problems is their job as org admin. As org admins, to some extent they can knock heads. You don't really want that, except as a last resort. Jessica is PSF org admin, with no specific interest in Mailman. A really last resort, because it implies Terri and Florian are asleep at the wheel. N.B. They all *like* talking to people when they've got time. Don't be *afraid* to talk to them. But it's better to spread yourself around (or as the Japanese say, develop a wide face) and get to know more people in the project, especially at the start. I am looking forward to contribute to Mailman in the upcoming Google Summer of Code 2014 through the Mailman SNMP Support Project idea. I have an experience with the open source software development and tools used. This is a good enough short self-introduction. However, it doesn't shine. It's like providing a numerical answer on a math test, without showing your work. (Boy do I hate it when students do that) Specifying languages (and implementations), maybe applications and libraries, related to the project that you have worked with, or especially on, polishes the image. Mention projects (an URL to your github page is just another numerical answer -- tell us about your work!) But keep it short (yes, I know it's difficult to do both). Image is important -- we mentors are all human, bright shiny things attract our attention. That's part of why we need org admins -- not everybody has image skills[1], so somebody has to go looking for and polishing up those diamonds in the the rough. But you can better your chances by not depending on the org admins to get attention for your proposal -- do it yourself. I have an indepth knowledge of SNMP protocol and an understanding of the concepts specified in the SNMP RFC 1157. Although I'm willing to co-mentor this project, when you first posted I was able to expand SNMP but that was the extent of my knowledge. (Standards geeking is one of the things I'm good at, I'm pretty sure I can catch up. :-) I had no clue about why Mailman would want it or who requested it or who would mentor it. So I didn't respond. The two whos are our bad (they should be on the Ideas page, partly remedied now). But it's important that *you* explain *why* you chose that feature. It's OK to just say it's in my toolkit (and do be honest about your motivations -- mentoring is a trust relationship). But, again, your proposal shines when you tell us why *we* (or our users) want it. So you (or any student) can greatly improve your chances of getting someone to engage by telling us why we want it. You do that by focusing on the *user requirements* rather than on the *design and implementation* (use this protocol is design; use this library is low-level design, aka a plan for implementation). Everybody on this list is a Mailman *user* (broadly defined as list members, list admins of several flavors, and site admins), but not all are *developers*. If you can get some users saying hey, *I* could *really* use that feature, it's more attractive to the developers and mentors (and we always have more desirable features than slots). But remember, users often don't know the buzzwords like SNMP (or even SMTP, and RFC numbers are quite arbitrary). Concretely, what are the benefits to subscribers and/or admins? Tell stories about situations where this feature would help. Describe how it would operate (from the user's viewpoint, not the protocol itself). N.B. This advice isn't universal. In some projects, mentors are core developers who are looking for someone just like them, who knows the protocol and just wants to dive in and implement a pre-specified feature. (That's typical for compiler optimizations, for example.) But I think it's pretty good advice for Mailman at the present time. *
Re: [Mailman-Developers] URLs in notification messages
Barry Warsaw writes: The basic problem is this: with the separation of web ui and core, the core can't actually know a priori what those links will be, or even if there *are* links. So in my branch I actually remove all those links from the default templates and rewrite as necessary to describe the email workflow. This sound like a job for bassoSuper NMP/basso. :-) ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Moderation rules priority
Aurelien Bompard writes: I'd like to discuss what happens when an email is sent by both a member and a nonmember in Mailman3. How is that possible? Very easy, here's my use case : I have my own domain, say example.com, and for convenience and portability I choose to use Gmail as a server/storage/interface. My main adress is al...@example.com and I redirect it to al...@gmail.com, while I set a default identity in gmail to al...@example.com which will set the proper From header. However, for spam detection and spoofing reasons, gmail adds a Sender header with al...@gmail.com. My outgoing emails thus have both a From and a Sender header, and in this case email clients only display the From header (except Outlook, but eh...) Your outgoing emails also have an envelope sender, which might be different from both of the above. Mailman now: when I subscribe to a list, I use my regular address, al...@example.com. But the message.senders property will contain both addresses because of the Sender header. The email goes through the MemberModeration rule, which finds my subscribed address and, by default, associates the defer action. The email then goes through the NonMemberModeration rule, which finds my Gmail address and sets the action to hold (it ignores my main address because it's a member already). What do you think about all that? Do you agree there's actually an issue there? Yes. Any idea how to solve it? For example, make the NonMember rule exit if a member is found amongst the senders (which would simply be equivalent to making it yield to the Member rule). Bad idea? Offhand I'd say that having both a Member rule and a NonMember rule is a bad idea. There should be one conceptual test: can we identify a member as the originator of this post? Having Member and NonMember rules that can both succeed is not coherent. I think that what should happen here is that the Member rule should try to identify the originator, and the NonMemberModeration (if in effect) should just check for a member_identified property. The member_identified property could be a Boolean or actually contain a list of members (list because it's not obvious what to do if each of From, Sender, and envelope sender corresponds to a different member; that would probably be a policy issue). I don't really see how order dependence can be avoided without violating DRY all over the place. Alternatively, NonMemberModeration might not be a rule, but rather a chain. Perhaps that's the most elegant solution, as order dependence between chains is necessary. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface
Bhargav Golla writes: I hope my mail hasn't missed your attention. I would be very much obliged if someone could answer this question so that I can go ahead and write proposal. First, it's impolite to send mail to specific people just because they're answered you before, unless they are specifically interested in mentoring your project or have requested personal mail. I don't think either is true (according to the wiki, there are no prospective mentors for this project -- I'm sure there are some, but they're not identified). Everybody reads this list, and by addressing them specifically you may be sending them duplicates. Note: no harm done this time, but you will be a much more valuable developer if you become sensitive to these marginal people skills. Second, you yourself have not responded to a somewhat detailed comment from Terri about using HTML5. I for one have been waiting for that. See also the Postorius Responsive UI project. Third, there's not much here to comment on is all I really have to say. From the Subject I can see that you're interested in a handheld interface. From the text you quote, I see you have a *very* basic grasp of the requirements of web protocols for this application. You probably know a heck of a lot more -- but that's all I can confirm from your posts. The way you ask is problematic. On the one hand, a GSoC proposal is not a homework for school. There are no right answers, only good ones and better ones. And you don't have to give a superior answer immediately to qualify, only show promise of heading in the right direction. (Of course, there are more students than slots, so you also have to show more promise than others. But you have another week or so to improve, and the delta can be in your favor.) On the other, it's not *one* question. Rather, it has a strong whiff of please write half my proposal (the hard half) for me. So just write your proposal so there's something to actually comment on. All that said, login screens are way clunky for modern handheld apps. Users expect a smooth convenient experience. Second, that experience does not include entering passwords on a frequent basis. You should look into including TLS authentication. These need not be present in the initial design, and maybe they won't even be in your delivered product. But you should think in terms of a design that allows easy upgrades to the UI. Steve Thanks On Mon, Mar 10, 2014 at 9:23 AM, Bhargav Golla bgo...@g.clemson.edu wrote: Hello I have gone through the Admin interface and all functions that can be achieved with the REST API. I intend to have a login screen where a user can enter URL for the REST API endpoint, REST Username and password. We will use this to subsequent authenticate all requests made to fetch subscribers list, domains list, etc. I was wondering if I could get some feedback on this. I will start writing my proposal based on this starting point and list out what all I would features I would be implementing during the period of GSoC. Regards On Wed, Mar 5, 2014 at 10:32 AM, Bhargav Golla bgo...@g.clemson.eduwrote: Thanks. I would have probably missed it out the first time. I will go through the web UI and also the documentation of REST API to understand what all functions need to be implemented in the admin interface for a user. Regards On Wed, Mar 5, 2014 at 10:25 AM, Rajeev S rajeevs1...@gmail.com wrote: Hi, You will be asked for the create user prompt only the first time you run syncdb.That's why you don't see it now. Once the DB is created, only new tables, specified via django models, get added to DB during the syncdb. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla bgo...@g.clemson.eduwrote: Hi Rajeev I wasn't asked if I wanted to create a super user when I executed python manage.py syncdb. This was the output I got with syncdb: Creating tables... Installing Custome SQL... Installing indexes... Installed 0 object(s) from 0 fixture(s) I tried python manage.py createsuperuser and was able to login with details I provided there. Thanks for your help. Regards On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S rajeevs1...@gmail.comwrote: Hi Bhargav, You will be asked whether to *add a superuser* during *syncdb*. If you answered no to that, do *python manage.py createsuperuser * and use that username and password to login. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla bgo...@g.clemson.eduwrote: Hi Abhilash If you mean the last step of installation where we do cd postorius_standalone;python manage.py syncdb,
Re: [Mailman-Developers] Moderation rules priority
Barry Warsaw writes: I'm having a hard time right now seeing how we could continue to support these types of operations with a combined member and non-member rule. I expressed myself poorly. The parameters of the decision logic given the list of senders are different for the two rules so both rules are needed. But I really think that determining the sender should be done in one place by one set of principles, separated from the to post or to moderate logic. Maybe we could use all_senders, member_senders, and apparent_sender properties (where the last is Mailman's best guess at who's reponsible for sending the mail for the purpose of moderation), or perhaps just apparent_sender and sender_is_member properties. I *think* the right solution may be to continue to keep the rules separate, but add an extra check to the nonmember-moderation rule, such that if any of the senders are members, then the rule cannot hit. This is horrible. You've already done that check in the Member rule. It's OK as a stop-gap, I don't really object applying to Aurelian's patch in principle, because I think it should be fixed now. The meta-rules about how to compose rulesets need discussion before doing anything more invasive. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface
Bhargav Golla writes: guess the culture varies from organization to organization Thank you for pointing this out. Indeed it does. ASF (and the PSF for that matter) have a lot more applicants, and at least the PSF is using a generic channel -- core-mentorship -- for GSoC and OPW interns. In those cases it makes a lot of sense to clearly indicate what the post is for, and who. In Mailman it happens to be the case that this list, although it is the generic developers list, is relatively low traffic, except at GSoC time. So we know what you're going to talk about. :-) and I should have been wary of this or should have followed usual email etiquette. It was wrong on my part I certainly wouldn't say wrong, as you apparently are already well- aware of the etiquette issues. You did your best. We can't ask for more than that given varying culture and needs. (Heck, I myself didn't clean up the headers) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Moderation rules priority
Barry Warsaw writes: I feel quite strongly that rules should be self-contained and unordered, with ordering imposed by the chain of links that rules are associated with. I don't understand what you're trying to say here. Are you saying that rules should not have a rules_to_run_before_this_rule field, but it's OK if a chain rule_B, rule_A is buggy because rule_A should be run before rule_B? Of course we should then fix the bug -- the point is that it is currently very easy for such bugs to occur, because rules may depend on metadata, and set/change metadata. Perhaps rules should be allowed to add new metadata, but not change existing metadata? I think I already mentioned that I have a difficulty with the concept of *pure* Boolean with side effects, too. :-) N.B. As far as *I* am concerned, you can take your time about responding to this. I need to go review the docs and code on all this anyway. But I suspect that if *I'm* confused about these concepts, *others* may be too, and they're pretty fundamental to customizing and extending Mailman 3. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [GSoC 2014] Proposal for Cordova App for GNU Mailman Admin Interface
Bhargav Golla writes: Also, I have observed on the PSF GSoC page that it requires students to submit a patch to the sub-organization. I like this one: https://bugs.launchpad.net/mailman/+bug/881320 Requires knowledge of gettext and the Python facilities for dealing with it (IIRC xgettext knows about Python now). I recommend searching Launchpad for the mailman3 tag; Mailman 2 bugs are somewhat likely to be harder bugs, and definitely solving Mailman 2 bugs is not as useful for learning Mailman architecture and coding -- not to mention requiring you to check out and find your way around a rather different source tree. HTH, I gotta get back to work... ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Testing MM3
Kẏra writes: Is there a page documenting how to start testing MM3 with postorius+hyperkitty and how to upgrade from MM2? The relevant and up-to-date documentation is mostly in the docs in the source trees of the various projects. Some effort has been made to update the wiki, but I doubt it's thorough. The Mailman sprint at PyCon in April is likely to spend time on this issue (hopefully only the 5 minutes needed to announce a previous success :-). ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Fwd: DMARC and Mail Lists open space at Pycon
Mark Sapiro writes: I have tentatively scheduled an open space for Friday, 11 April at 18:00 in room 523B at Pycon to talk about DMARC and mail lists. All available interested parties are invited. If the time doesn't work, we can reschedule. Is that EST or EDT? I'll try to be around on IRC, if somebody can occasionally forward the sense of the conversation to me. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Just to follow up quickly (I've got problems I need to deal with elsewhere over the next couple days). Abhilash Raj writes: Hey, thanks for jumping in, maxking! Hi Rajeev, Congratulations! We look forward to a great summer with you. Definitely! I would like to thank the Mailman community and mentors for their extensive support during my application process, You're very welcome. Also I have a few questions as part of the community bonding process. 1.Is the project to be developed as an independent project or as a part/branch of the Mailman Core repository That is supposed to be an implementation detail of your proposal. What do you think would be the best? I agree with Abhilash. You make a proposal, we'll criticize it (contructively; criticism is not necessarily negative, just as with literary critics we may give a positive review -- you should know when you're doing things right). 2.If it is an Independent project, Is it OK to use the git+gitorious/savannah or should I stick to bzr+launchpad? I have used git extensively,naturally more comfortable with git. However, I can pick up bzr if necessary. Even if it is an independent project we strongly encourage you to use bzr, as integration and code review might become a problem in later stages of your project( I am speaking from personal experience). Learning bzr and launchpad is not at all difficult if you know git. The CLI won't be *that* independent. It really needs to be on Launchpad. Note: It may be possible to use git-bzr to fetch and push from Launchpad. 3.Is it necessary for me to hangout in the IRC?If yes, when? It is not *necessary* for you to hangout on IRC. You just need to keep your mentors updated about what are you doing all the time. If you prefer email, I don't think that would be a problem. Your only responsibility is to deliver the project you proposed on time. It's generally a good idea to have interaction (brainstorming) when working on design. I can generally be available on IRC from about 01:00 UTC to 15:00 UTC. As Abhilash knows :-) I can often be convinced to stay around until about 17:00 UTC. yaseppochi @ freenode 4.Can I start coding right away? You can, but first be sure you know what you want to code. Your proposal does have a detailed description on working of the tool, however there is little mention about the details of implementation and design. It would be best if you first consult with your mentors and decide on something so that you don't waste time writing code that is not needed. Read Fred Brooks' /The Mythical Man-Month/, especially the essay Build One to Throw Away. Then think about whether you really believe him. :-) Regards and looking forward to working with you! Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Rajeev S writes: You do a *heroku login *from your shell and you can run commands on the remote server of your application from your shell.This would be an interesting project and would hugely benefit usability of the current project. Sure, under the hood this is just an ssh login, most likely. However, I wouldn't bet on it being hugely useful, as these days most Mailman list owners share a Mailman site using cPanel or similar, and don't have shell access at all. *Very* useful in beta test, though. That seems like a funny GMail bug. All I did was to reorder the terms of the phrase which was in boldface, using cut and paste. Anyway, I will remember not to do this again. Aargh. HTML mail is a tool of the devil. It is not a hacker's friend, it makes life annoying for filtering and automatic mail processing. When you get ~250 wanted mails (many of them list, of course) and ~1000 spams (that get past the 6-sigma if this filter thinks it's spam, throw it away! filter) a day, automatic processing is really important. Unfortunately I don't have a copy of your original, but what may be happening is not at GMail, but rather that the mailing list tries pretty hard to avoid HTML mail, throwing away the text/html part if there's a text/plain alternative, and otherwise running it through an HTML-to-text converter (probably Lynx with output to a file). It could also just be my local MUA, which I have set up to try to minimize the HTML mail that I see. Mark can probably say with some confidence. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Tanstaafl writes: On 4/27/2014 11:03 AM, Stephen J. Turnbull step...@xemacs.org wrote: When you get ~250 wanted mails (many of them list, of course) and ~1000 spams (that get past the 6-sigma if this filter thinks it's spam, throw it away! filter) a day, automatic processing is really important. ? Anyone who gets ~1000 spams per day that actually make it through whatever anti-spam tools you are employing, I didn't say that I actually see them, I said I get 1000 that can't be rejected/discarded as spam with 6-sigma accuracy. Dealing with the 1-in-100 Type II errors and the 2-in-100 Type I errors in the 1000 is what much of the automatic processing is for. then you need different/better anti-spam tools. Suggestions are welcome. Most of the problematic mail is in Japanese or Chinese however, and I don't know any tools (including GMail which throws up false positives in my spam folder about once a week) that get 2- or 3-sigma performance on those languages, at least not in my multilingual context. So I quarantine, and do a lot of tweaking of packaged tools and postprocessing myself. At least some commercial tools for Japanese are really horrible -- about once a week I get mail from a colleague that is marked as spam or suspected spam by my *employer*'s filters, and traffic on this list gets marked that way about as often. :-( ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
