From daniel at cacert.org Thu Oct 1 10:57:27 2009 From: daniel at cacert.org (Daniel Black) Date: Thu, 1 Oct 2009 18:57:27 +1000 Subject: [Mailman-Developers] dkim and email list software - potential solution Message-ID: <200910011857.31254.daniel@cacert.org> I proposed some ideas around DKIM compatibility with mail lists and tried to send here too. Obviously the anti-cross-post feature on mailman- developers at python.org is working well (which on some levels I appreciate). As leading maillist product I'm keep to know your opinion. This has obviously been mentioned before never quite got momentum[1]. Now that ADSP (RFC 5617) is out it seems that validating domains with a ADSP policy of dkim=all seems rather weak as anything other than a temporary spam bias (until spammers catch on). My nice controversial idea is to mangle the from: address in mailing lists in general so that the list domain becomes the author (for ADSP purposes) and those DKIM validating emails are given the ability to do more with ADSP than spam biasing. Original post here http://mipassoc.org/pipermail/dkim-dev/2009- September/000202.html Other ideas welcome. [1] http://wiki.list.org/display/DEV/DKIM -- Daniel Black Infrastructure Administrator CAcert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From iane at sussex.ac.uk Wed Oct 7 12:00:52 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 07 Oct 2009 11:00:52 +0100 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910011857.31254.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> Message-ID: <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> As far as I recall, Mailman removes DKIM signatures, and re-signs messages. You're saying that with ADSP, that's not adequate unless Mailman first rewrites the "From:" address. Some lists are configured to do this already, the question is what to do about those that don't. Dave Crocker suggests that it's not the business of the list to fix this. That's true, but it is sensible to discuss how list managers could address the problem, and it's certainly useful to be aware of the problem - even if we conclude that list managers should not attempt to resolve it. It seems to me that it's sensible for the list software to test the DKIM signature before and after any changes it makes to the message. And apply these policies: Good before, good after: deliver the message as normal. Bad before (broken DKIM sig, or missing a sig that ADSP says should be there), reject the message at SMTP time, but that's the MTA's job. Good before, "discardable" after: If the DKIM signature is good, and the return-path is is signed, we can comfortably generate a bounce message. Otherwise, I guess we should reject at SMTP time, or bounce to the From address, perhaps? Effectively, you're saying to the sender "you've asked the recipient to discard the message that I'm about to send on your behalf, I'm going to save them the trouble". The RFC warns that use of "discardable" means that you're unlikely to get the message through a mailing list, but I think it's better to alert the sender. Rejection at SMTP time might be more practicable because a significant proportion of such email is from addresses that don't accept bounce messages! The MTA would need to know whether the list was going to rewrite the From: header, I suppose. Bad before, bad after: (DKIM or ADSP fail), reject the message at SMTP time if possible. That's the job of the border MTA, though. Bad before, good after: presumably this is a list that rewrites From headers, but I don't think we want this message, so we should reject at SMTP time. Alternatively, if the ADSP policy is "discardable", we can discard it without guilt. Again, this is probably the job of the border MTA. If the ADSP policy is "all", then I don't see a problem. The recipient should not reject a message from a mailing list just because it doesn't carry a matching signature. This is expected behaviour: we know the message was sent with a signature, we know the message came from a mailing list, we know the list was going to break or remove the signature. We should, however, look for a signature from the mailing list, and we should apply initial reputation tests (and modifications) to the list, not the original sender. If the list has good reputation, we should assume that it tested ADSP, and found a good DKIM signature on the original message. We can, therefore continue and check (and modify) the reputation of the original sender. That last paragraph makes the job of reputation assignment harder where mailing lists are concerned - but that's to be expected. The whole point of DKIM, as far as I'm concerned, is to allow more sophisticated assessment and assignment of reputation scores. --On 1 October 2009 18:57:27 +1000 Daniel Black wrote: > > I proposed some ideas around DKIM compatibility with mail lists and tried > to send here too. Obviously the anti-cross-post feature on mailman- > developers at python.org is working well (which on some levels I appreciate). > > As leading maillist product I'm keep to know your opinion. This has > obviously been mentioned before never quite got momentum[1]. Now that > ADSP (RFC 5617) is out it seems that validating domains with a ADSP > policy of dkim=all seems rather weak as anything other than a temporary > spam bias (until spammers catch on). > > My nice controversial idea is to mangle the from: address in mailing > lists in general so that the list domain becomes the author (for ADSP > purposes) and those DKIM validating emails are given the ability to do > more with ADSP than spam biasing. > > Original post here http://mipassoc.org/pipermail/dkim-dev/2009- > September/000202.html > > Other ideas welcome. > > [1] http://wiki.list.org/display/DEV/DKIM -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane at sussex.ac.uk Wed Oct 7 15:54:41 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 07 Oct 2009 14:54:41 +0100 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910080021.15352.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> <200910080021.15352.daniel@cacert.org> Message-ID: <60802042009775949479B3FF@lewes.staff.uscs.susx.ac.uk> --On 8 October 2009 00:21:08 +1100 Daniel Black wrote: > >> You're saying that with ADSP, that's not adequate unless Mailman first >> rewrites the "From:" address. > yes, as its easiest place in the whole signing verification scenario to > make a change that benefits the most people without adversely effecting > anyone significantly. > >> Some lists are configured to do this already, > I didn't know this. Anyone know who these are and if they incur any > problems as result of this rewrite? > In Mailman, it's the "anonymous_list" setting, described thus: "anonymous_list (general): Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields)" Probably mostly used for announcement only lists. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane at sussex.ac.uk Wed Oct 7 15:56:57 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 07 Oct 2009 14:56:57 +0100 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910080021.15352.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> <200910080021.15352.daniel@cacert.org> Message-ID: --On 8 October 2009 00:21:08 +1100 Daniel Black wrote: >> It seems to me that it's sensible for the list software to test the DKIM >> signature before and after any changes it makes to the message. > You can tell from the mailing list settings if it will break without > revalidating it. Same policies apply though. Doesn't that depend on what's signed, as well as what the list is going to alter? Agreed, though, this is an implementation detail. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane at sussex.ac.uk Wed Oct 7 16:02:14 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 07 Oct 2009 15:02:14 +0100 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910080021.15352.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> <200910080021.15352.daniel@cacert.org> Message-ID: --On 8 October 2009 00:21:08 +1100 Daniel Black wrote: > >> we know the message came from a mailing list, > this actually is the hard bit. Options for the recipient verifier are: > 1. has a List-ID (or other signature) - must be a mailist. This allows > email spoofers just to add List-ID tags or a simple email characteristic > to bypass checking. > 2. manage a whitelist of maillists that have subscribers in the domain, > that can't be easily spoofed. Pretty easy for small domains but many > thousand user bases requires more admin time or run the risk of a user > whitelisting a spoofer IP address. > 3. originator specified third party signatures - discussion (re)-starting > on IETF WG list on this. Bit labour intensive on the sender part. > (http://mipassoc.org/pipermail/ietf-dkim/2009q4/thread.html) Well, my reputation assessment scheme says you should check the DKIM signature added by the list's domain, if there is one. You only trust the list if you have reason to. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane at sussex.ac.uk Wed Oct 7 16:10:49 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 07 Oct 2009 15:10:49 +0100 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910080021.15352.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> <200910080021.15352.daniel@cacert.org> Message-ID: --On 8 October 2009 00:21:08 +1100 Daniel Black wrote: > >> That last paragraph makes the job of reputation assignment harder where >> mailing lists are concerned - but that's to be expected. The whole point >> of DKIM, as far as I'm concerned, is to allow more sophisticated >> assessment and assignment of reputation scores. > Though it can contribute to reputation scores this is taking a strong > cryptographic signature method and contributing it towards a spam score. > This only goes so far defeating some forms of phishing. DKIM helps you determine whether an email really was sent by the purported sending domain. If it wasn't, that's bad. If it was, that doesn't mean it's good, but it does allow you to check the sending domain (or sender) against your reputation database, and to modify your view of the sender's reputation based on the current email. Currently, all we really have that's useful for reputation assignment are content (too complex) and IP source (too often shared between good and bad senders). I'm not saying they're not useful, and there are even some sender addresses that you can blacklist. Without DKIM and SPF, you can't really build a reputation infrastructure for sender addresses, because for most spam you're checking or modifying the reputation of an innocent third party. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From mark at msapiro.net Wed Oct 7 16:42:26 2009 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 7 Oct 2009 07:42:26 -0700 Subject: [Mailman-Developers] Script to change a member's password In-Reply-To: <4AC26AA1.9090003@labitat.dk> Message-ID: Marc Juul wrote: > >I'm running mailman 2.1.11 and i wrote a script to change a user's >password, but it doesn't change anything and i can't seem to find the >problem. My other "withlist" scripts work fine. > >I'm using: > > mlist.setMemberPassword(member, password) > >and then > > mlist.Save() Those are the appropriate methods. >called using "withlist -l -r" > >I have attached my script. Which didn't make it through this list's contentent filtering. Try again, renaming it with a .txt extension so it gets a mime content type of text/plain -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From dnovotny at redhat.com Wed Oct 7 12:54:27 2009 From: dnovotny at redhat.com (Daniel Novotny) Date: Wed, 7 Oct 2009 06:54:27 -0400 (EDT) Subject: [Mailman-Developers] a patch: init script cleanup for LSB compliance In-Reply-To: <1241621296.1137011254912787298.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <234691001.1137031254912867781.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> hello, There's an effort in Fedora to improve all our init scripts for better LSB compliance. Because I'm responsible for mailman package here, I made following changes in the mailman init scripts: * when mailman is unconfigured, `service mailman start' should exit with code 6, not 1. * `try-restart' was't implemented. This is an addition to condrestart and should have the same effect. * stopping mailman when already stopped doesn't print scary error message now, prints "mailman already stopped" instead * when /var/lock/subsys/mailman exists but mailman isn't running, and `service mailman status' was executed, the script just printed 'mailman is stopped' and exited with code 3. In this case, it should say that it's dead but its subsys is locked, and exit with code 2. * when no known parameter is passed to the init script, it should exit with code 2, not 3. patch attached, references: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html (Linux Standard Base init scripts specification) https://bugzilla.redhat.com/show_bug.cgi?id=524016 (Red Hat bugzilla entry addressing mailman init scripts) best regards, Daniel Novotny, Red Hat inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman-2.1.12-initcleanup.patch Type: text/x-patch Size: 1462 bytes Desc: not available URL: From daniel at cacert.org Wed Oct 7 15:21:08 2009 From: daniel at cacert.org (Daniel Black) Date: Thu, 8 Oct 2009 00:21:08 +1100 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> Message-ID: <200910080021.15352.daniel@cacert.org> On Wednesday 07 October 2009 21:00:52 Ian Eiloart wrote: > As far as I recall, Mailman removes DKIM signatures, yes > and re-signs messages. not that I recall though the MTA is free to sign it on the way out and I encourage all list owners to do so. > You're saying that with ADSP, that's not adequate unless Mailman first > rewrites the "From:" address. yes, as its easiest place in the whole signing verification scenario to make a change that benefits the most people without adversely effecting anyone significantly. > Some lists are configured to do this already, I didn't know this. Anyone know who these are and if they incur any problems as result of this rewrite? > the question is what to do about those that don't. > > [not mailing list obligation to fix problem]..., but it is sensible to discuss how list managers could address the problem, thank you > It seems to me that it's sensible for the list software to test the DKIM > signature before and after any changes it makes to the message. You can tell from the mailing list settings if it will break without revalidating it. Same policies apply though. > And apply these policies: > > Good before, good after: deliver the message as normal. > > Bad before (broken DKIM sig, or missing a sig that ADSP says should be > there), reject the message at SMTP time, but that's the MTA's job. yes. very easy to do. including dropping broken sigs etc where dkim=all? > > Good before, "discardable" after: ....(cut).... Rejection at > SMTP time > The MTA would need to know whether the list was going to rewrite the From: > header, I suppose. yes - requested feature just added for this: https://sourceforge.net/tracker/?func=detail&aid=2874043&group_id=269812&atid=1147704 > Bad before, bad after: (DKIM or ADSP fail), reject the message at SMTP time > if possible. That's the job of the border MTA, though. yes > > Bad before, good after: presumably this is a list that rewrites From > headers, but I don't think we want this message, so we should reject at > SMTP time. agree > If the ADSP policy is "all", then I don't see a problem. The recipient > should not reject a message from a mailing list just because it doesn't > carry a matching signature. This is expected behaviour: we know the message > was sent with a signature, > we know the message came from a mailing list, this actually is the hard bit. Options for the recipient verifier are: 1. has a List-ID (or other signature) - must be a mailist. This allows email spoofers just to add List-ID tags or a simple email characteristic to bypass checking. 2. manage a whitelist of maillists that have subscribers in the domain, that can't be easily spoofed. Pretty easy for small domains but many thousand user bases requires more admin time or run the risk of a user whitelisting a spoofer IP address. 3. originator specified third party signatures - discussion (re)-starting on IETF WG list on this. Bit labour intensive on the sender part. (http://mipassoc.org/pipermail/ietf-dkim/2009q4/thread.html) > we > know the list was going to break or remove the signature. We should, > however, look for a signature from the mailing list, yes good. this falls nicely into #2 above, A strong signature of the email list to whitelist. More fully mailing lists should DKIM sign emails (after dropping invalid signatures). > and we should apply initial reputation tests (and modifications) to the list, not the original sender. If the list has good reputation, we should assume that it tested ADSP, and found a good DKIM signature on the original message. We can, therefore continue and check (and modify) the reputation of the original sender. If you have a method of determining if it a list in 1-3 above then this works as mailing list domains should gain good reputation quickly (though varying list policy between lists or large list servers like sourceforge.net could hide bad in the reputation of the majority). If you are blindly assessing an email without knowledge that is a mailing list what do you see? You can check the reputation of the domain on a third party DKIM signature and treat this like a mail list above. What would it mean for a new list domain/third party sender? My assumption, based on not much experience with reputation services, is neutral reputation will allows the email though. Scenario 1: Putting names on this. Phisher Mallory buys a domain friendly.org sets up DKIM on it. Mallory sends email to Bob saying that Bob needs to validate his credentials with Bank of Alice. The author of the email looks like Bank of Alice (who says has an ADSP policy of dkim=all). Bob's university who filters his email doesn't know about friendly.org, so checks it reputation: (pick an ending) a) it has a neutral reputation, so lets it though and Bob gets scammed. b) it has a negative reputation. and gets blocked after Mallory got detected sending lots of phishing email and gaining lots of money out of the Bank of Alice's customers all for the cost of a domain that wasn't visible to the end victim. Sure this is all the receiver's problem. The receiver's problem would also be easier if, say in 4 years time, when mailman 3 and 4 are common place, and has been rewriting From addresses for years, and the end verifier has a small whitelist on third party signatures and most spoofing is dropped using ADSP. > That last paragraph makes the job of reputation assignment harder where > mailing lists are concerned - but that's to be expected. The whole point of > DKIM, as far as I'm concerned, is to allow more sophisticated assessment > and assignment of reputation scores. Though it can contribute to reputation scores this is taking a strong cryptographic signature method and contributing it towards a spam score. This only goes so far defeating some forms of phishing. The IETF WG Charter (http://tools.ietf.org/wg/dkim/charters) describes DKIM as "Taken together[signature and policy], these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain." not there yet..but I can't too many easy solutions either. -- Daniel Black Infrastructure Administrator CAcert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mark at msapiro.net Wed Oct 7 17:36:59 2009 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 7 Oct 2009 08:36:59 -0700 Subject: [Mailman-Developers] a patch: init script cleanup for LSB compliance In-Reply-To: <234691001.1137031254912867781.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Daniel Novotny wrote: > >There's an effort in Fedora to improve all our init scripts >for better LSB compliance. Because I'm responsible for mailman >package here, I made following changes in the mailman init scripts: The patch you included is against RedHat's already heavily modified mailman-2.1.12/misc/mailman.in. See for the current upstream version. Also see for an issue that may or may not affect this. I am happy to consider incorporating these changes upstream, but I need the whole file or a patch against my base. I also need the RedHat changes to bin/mailmanctl that support the 'status' and perhaps other RedHat extensions. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Thu Oct 8 08:07:30 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 08 Oct 2009 15:07:30 +0900 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910080021.15352.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> <200910080021.15352.daniel@cacert.org> Message-ID: <87y6nmquzh.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Black writes: > > You're saying that with ADSP, that's not adequate unless Mailman > > first rewrites the "From:" address. > yes In that case it is very often a violation of RFC 733 (most familiarly known as RFC 822, also STD 11, whose most recent incarnation is RFC 5322). Surely you already know that! That's a *lot* of history of best practice that you are dismissing, it's not going to be acceptable to a lot of folks, and in general sucks for users of discussion lists. Personally, I'd much rather have my posts dropped. "Oh yes, your ISP regularly drops mail because they use broken spam-fighting practices. It's not just us, it's every list that conforms to one of the oldest Internet standards. If you want to receive your list mail, either subscribe with an address hosted at a decent ISP, or get your current one to fix their spam filters." Most of my users are well-informed, and quite sympathetic to that argument because they've seen it happen any number of times. I really would not appreciate it if "worst practices" were to become widespread because they cater to the unwashed who just don't want to receive spam and don't care who pays the cost (as long as it's not them). Wouldn't it be more straightforward (not to mention that it would work for many more lists) to have an LDSP RFC, whose first draft simply takes the ADSP RFC and substitutes "mailing list" for "author" everywhere, and "RFC 2369 and RFC 2919 headers" for "From"? (The point of multiple headers is that "active" headers like List-Subscribe could contain bogus URLs.) A second draft might add "If the list's host implements ADSP itself, it could also sign the author headers relevant to ADSP." Perhaps if it is known that the DKIM signature of the author's host is going to remain valid, you *don't* sign it, allowing the recipient to authenticate both the author and the list. The only real problem with this is getting the big ISPs to implement, but that's nothing new. In fact if it's as easy as adding routines to process the RFC 2369 + RFC 2919 set of headers "just like" ADSP handles "From:", I bet most would be happy to sign on. > > Some lists are configured to [rewrite From:] already, > I didn't know this. Anyone know who these are and if they incur any > problems as result of this rewrite? Announce lists are special-purpose lists, ironically mostly used for something very similar to spamming (except of course, legitimate "announce" lists are willingly subscribed to). These are quite common; they also already fit into the ADSP framework quite well, so are basically irrelevant to your proposal. Anonymous discussion lists are special-purpose lists used by folks like victims of domestic violence. These are a very good thing IMO, but again they are not a model for other lists. > If you are blindly assessing an email without knowledge that is a > mailing list what do you see? If the list doesn't implement any of RFC 2369 (published 1998) or RFC 2919 (published 2001), the joke is on it. Otherwise you shouldn't be blind. I think it is reasonable to assume that mailing lists are easily identifiable by the presence of those headers. For that precise reason, I propose that they be used instead of "From:" for ADSP-like authentication of mailing lists. This is so obvious that I suspect there's some "good" reason why it won't work, but as long as a harmful alternative is being suggested, may as well give it a try. From daniel at cacert.org Fri Oct 9 05:22:18 2009 From: daniel at cacert.org (Daniel Black) Date: Fri, 9 Oct 2009 14:22:18 +1100 Subject: [Mailman-Developers] =?iso-8859-1?q?dkim_and_email_list_software_?= =?iso-8859-1?q?-_potential=09solution?= In-Reply-To: <87y6nmquzh.fsf@uwakimon.sk.tsukuba.ac.jp> References: <200910011857.31254.daniel@cacert.org> <200910080021.15352.daniel@cacert.org> <87y6nmquzh.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <200910091422.23721.daniel@cacert.org> Stephen, Thanks you for your responses. On Thursday 08 October 2009 17:07:30 Stephen J. Turnbull wrote: > In that case it is very often a violation of ... RFC 5322). Surely you already know that! thanks for the reminder. > That's a *lot* of history of best practice that you are dismissing, There's lots I don't know and I am keen to learn too. > it's not going to be acceptable to a lot of folks, Apart from the assertions of mailing list software developers I'm yet to receive a strong assertion from list operators or users. Even less forthcoming is the reasons the lack of acceptability that could guide standards or implementations. > > and in general sucks for users of discussion lists. Personally, I'd > much rather have my posts dropped. "Oh yes, your ISP regularly drops > mail because they use broken spam-fighting practices. It's not just > us, it's every list that conforms to one of the oldest Internet > standards. If you want to receive your list mail, either subscribe > with an address hosted at a decent ISP, or get your current one to fix > their spam filters." Most of my users are well-informed, and quite > sympathetic to that argument because they've seen it happen any number > of times. I really would not appreciate it if "worst practices" were > to become widespread because they cater to the unwashed who just don't > want to receive spam more any phishing than spam. > and don't care who pays the cost (as long as it's not them). there's a development cost that I'll consider contributing to but I'm not going to develop stuff that has no change of being accepted. I will consider writing patches for: 1. global dkim-friendly= true to disable list modifications parameters 2. From: rewriting > > > Wouldn't it be more straightforward (not to mention that it would work > for many more lists) to have an LDSP RFC, whose first draft simply > takes the ADSP RFC and substitutes "mailing list" for "author" > everywhere, and "RFC 2369 and RFC 2919 headers" for "From"? (The > point of multiple headers is that "active" headers like List-Subscribe > could contain bogus URLs.) Doing so would allow List-* headers to be added by every spoofer, add their own signature and get immunity from spoofing every author domain while the end user doesn't notice because the List-* headers are hidden in the MUA (in most cases). > A second draft might add "If the list's host implements ADSP itself (as verification i'm assuming) > , it could also sign the author headers relevant to ADSP." A proposal for author domains to authorize third party lists is in development. http://mipassoc.org/pipermail/ietf-dkim/2009q4/012592.html It does place a large burden on author domains to deploy DNS records pre- presenting every list their user base send email too. > Perhaps if it is known that the DKIM signature of the author's host is going to remain valid, this would be idea. > you *don't* sign it, allowing the recipient to authenticate both the author and the list. Adding another list signature gives the mechanism to the recipient to validate the list and doesn't invalidate the original author signature. > The only real problem with this is getting the big ISPs to implement, > but that's nothing new. In fact if it's as easy as adding routines to > process the RFC 2369 + RFC 2919 set of headers "just like" ADSP > handles "From:", I bet most would be happy to sign on. So this is for mailing list that send though big ISPs that can't apply their own DKIM signatures? Not totally sure what you mean here though signing is the easy part compared to applying filtering on verification results. > > > Some lists are configured to [rewrite From:] already, > > > > I didn't know this. Anyone know who these are and if they incur any > > problems as result of this rewrite? > > Announce lists .........fit into the ADSP framework quite well, so > are basically irrelevant to your proposal. ack. > Anonymous discussion lists are special-purpose lists used by folks > like victims of domestic violence. These are a very good thing IMO, > but again they are not a model for other lists. ack. > > > If you are blindly assessing an email without knowledge that is a > > mailing list what do you see? > > If the list doesn't implement any of RFC 2369 (published 1998) or RFC > 2919 (published 2001), the joke is on it. its more the consideration that, as a verifier, you shouldn't trust a List-ID as a way to bypass filtering. > Otherwise you shouldn't be > blind. I think it is reasonable to assume that mailing lists are > easily identifiable by the presence of those headers. For that > precise reason, I propose that they be used instead of "From:" for > ADSP-like authentication of mailing lists. > > This is so obvious that I suspect there's some "good" reason why it > won't work, as provided. > but as long as a harmful alternative is being suggested, > may as well give it a try. please explain why this is harmful. It seems that anonymous discussion lists have worked so slightly manipulated From addresses would also work. Just take the return-path variant, From: "Daniel Black via mailman-developers list" and add a reply-to: daniel at cacert.org if the header field doesn't exist for MUA compatibility. -- Daniel Black Infrastructure Administrator CAcert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From carson at taltos.org Fri Oct 9 11:38:10 2009 From: carson at taltos.org (Carson Gaspar) Date: Fri, 09 Oct 2009 02:38:10 -0700 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910091422.23721.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <200910080021.15352.daniel@cacert.org> <87y6nmquzh.fsf@uwakimon.sk.tsukuba.ac.jp> <200910091422.23721.daniel@cacert.org> Message-ID: <4ACF0482.4020500@taltos.org> Daniel Black wrote: > On Thursday 08 October 2009 17:07:30 Stephen J. Turnbull wrote: > >> Wouldn't it be more straightforward (not to mention that it would work >> for many more lists) to have an LDSP RFC, whose first draft simply >> takes the ADSP RFC and substitutes "mailing list" for "author" >> everywhere, and "RFC 2369 and RFC 2919 headers" for "From"? (The >> point of multiple headers is that "active" headers like List-Subscribe >> could contain bogus URLs.) >> > Doing so would allow List-* headers to be added by every spoofer, add their > own signature and get immunity from spoofing every author domain while the end > user doesn't notice because the List-* headers are hidden in the MUA (in most > cases). > And this is different from sending signed mail From: IAmScum at SpammersRUs.com how? If you're answer is "appearance in the MUA" then the answer is to fix the MUA. Besides, any halfway decent anti-UCE technology will quickly ban the signing domain, limiting any user impact (although making life more difficult for mailing list admins without aggressive anti-UCE measures of their own). -- Carson From stephen at xemacs.org Fri Oct 9 13:55:22 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 09 Oct 2009 20:55:22 +0900 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <200910091422.23721.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <200910080021.15352.daniel@cacert.org> <87y6nmquzh.fsf@uwakimon.sk.tsukuba.ac.jp> <200910091422.23721.daniel@cacert.org> Message-ID: <877hv4n5n9.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel, > > [hacking the from] is not going to be acceptable to a lot of folks, > Apart from the assertions of mailing list software developers I'm > yet to receive a strong assertion from list operators or > users. Er, do you think we write open source purely out of charity? We are all operators and users ourselves. (Non-developer) users and list operators? See http://wiki.list.org/display/DOC/From+field+displayed+by+Microsoft+Outlook for what they think of the kind of display the munging you suggest produces. (The point is it's a FAQ; they *do not* like it.) And can you imagine what that will look like when combined with the munging you suggest Mailman do to fake out ADSP? > Even less forthcoming is the reasons the lack of acceptability that > could guide standards or implementations. 1. Spoofing authorship is what the phishers and the spammers do. We're the good guys, remember? Note that the name of the standard you are trying to promote here is *Author* Domain Signing Policy. What that means is that the list's domain is claiming authorship of the post. This is problematic in any number of ways. 2. Authorship information is lost, or at best obscured. You point out that most MUAs don't present List-* headers. Well, they don't present Sender or In-Reply-To either (except for Outlook). You're either in the From header, or the users don't know about it. 3. Sophisticated users filter on From. This breaks the filters bigtime once, and makes them more fragile forever after. 4. It's ugly. > there's a development cost that I'll consider contributing to but I'm not > going to develop stuff that has no change of being accepted. > I will consider writing patches for: > 1. global dkim-friendly= true to disable list modifications parameters > 2. From: rewriting 1. dkim-friendly is CAN-SPAM unfriendly. Specifically, best practice (and maybe the law AIUI) requires you to put an unsubscribe notice in somewhere. As you point out, the List-Unsubscribe header just won't do.... 2. From: rewriting. Thank you, but it is already a feature of most list software because it is required for common applications (announce lists, anonymous lists, and probably others I don't remember offhand). Adapting that to this purpose is nearly trivial. > > Wouldn't it be more straightforward (not to mention that it would work > > for many more lists) to have an LDSP RFC, whose first draft simply > > takes the ADSP RFC and substitutes "mailing list" for "author" > > everywhere, and "RFC 2369 and RFC 2919 headers" for "From"? (The > > point of multiple headers is that "active" headers like List-Subscribe > > could contain bogus URLs.) > Doing so would allow List-* headers to be added by every spoofer, > add their own signature and get immunity from spoofing every author > domain while the end user doesn't notice because the List-* headers > are hidden in the MUA (in most cases). Nonsense. 1. ADSP is vulnerable, too. Besides the Safemail! hack described below, there are any number of obscure RFC 822 features (and yes, they're still present in RFC 5322) available: From: cs at yourbank.com (Customer Service) .phisher.net 2. Anybody who is sufficiently unsophisticated or distracted to get caught by any of the email phishing scams I've seen is not going to be checking ADSP on authors, anyway. So this is *not* about users, it's about ISPs/email providers. *They* see *all* the headers, and they either filter (based on reputation) or provide notification of authentication results to users. Eg, Google and other providers tag mail "This mail probably did not come from the purported author. Don't click on anything in it." Mail which is only LDSP-authenticated can be tagged "This mail failed author authentication. Do not provide personal information to its sender by replying to it or clicking on anything in it." 3. List mail by its very nature (lists are traffic aggregators) is unreliable. Obviously the amount of trust you put in LDSP- authenticated mail is *much* lower than that you put in ADSP- authenticated mail. Still, in the current environment I'll take any bonuses I can get, and as long as I behave, I suspect the big ISPs would be willing to allow me to build up some cred. 4. ADSP is just as meaningless as LDSP, unless it comes from a reputable party. As has been pointed out already in this thread, DKIM and ADSP are helpful only because they allow ISPs to keep a reputation database based on reliable identification of sender domains. You don't rely on something just because it's signed. LDSP is the same (but attenuated, #3 still applies). > A proposal for author domains to authorize third party lists is in > development. http://mipassoc.org/pipermail/ietf-dkim/2009q4/012592.html > > It does place a large burden on author domains to deploy DNS records pre- > presenting every list their user base send email too. So it certainly loses in my use case: I run support lists. I really don't think someone whose editor has crashed and wants to know if they can recover the data they were editing is going to wait for IT to deploy DNS records before posting. > > Perhaps if it is known that the DKIM signature of the author's > > host is going to remain valid, > this would be idea. Sure, but it's rarely the case. See "best practice and unsubscribe", above. > > The only real problem with this is getting the big ISPs to implement, > > but that's nothing new. In fact if it's as easy as adding routines to > > process the RFC 2369 + RFC 2919 set of headers "just like" ADSP > > handles "From:", I bet most would be happy to sign on. > So this is for mailing list that send though big ISPs that can't > apply their own DKIM signatures? Not totally sure what you mean > here though signing is the easy part compared to applying filtering > on verification results. No, my mailing lists, and those like them, can deploy signatures and DNS easily enough. The question about the big ISPs is will they bother to do something to make things more comfortable for discussion lists. > > > If you are blindly assessing an email without knowledge that is a > > > mailing list what do you see? > > > > If the list doesn't implement any of RFC 2369 (published 1998) or RFC > > 2919 (published 2001), the joke is on it. > its more the consideration that, as a verifier, you shouldn't trust > a List-ID as a way to bypass filtering. Nonsense. It depends on the reputation of the list and the sending domain, just like From, which is just as easy to spoof, and reasonably easy to confuse the gullible. > please explain why this is harmful. Ugly (makes every MUA look as broken as Outlook). The From header is an *Originator header*; it is a violation of the RFCs to change it. > It seems that anonymous discussion lists have worked so slightly > manipulated From addresses would also work. Apples and asteroids, for heaven's sake. *You* want them to work, so you call completely different contexts similar. > Just take the return-path variant, > From: "Daniel Black via mailman-developers list" > > and add a reply-to: daniel at cacert.org if > the header field doesn't exist for MUA compatibility. Reply-To is also an originator field, munging it violates the RFCs. It's not obvious what the right thing to do if the Reply-To field exists. For example, I often set it to a list. And, per your suggestion, let's just take that return-path variant and see what we can do with it. From: "JP Morgan Customer Service via SafeMail!" Uh-oh. I *know* I've seen *that* domain somewhere before. Now, right now that looks suspicious. But once people get used to jumbles like From: "Daniel Black via mailman-developers list" they will stop trying to parse addresses at all (assuming the poor phish ever did in the first place). From barry at python.org Fri Oct 9 21:04:01 2009 From: barry at python.org (Barry Warsaw) Date: Fri, 9 Oct 2009 15:04:01 -0400 Subject: [Mailman-Developers] dkim and email list software - potential solution In-Reply-To: <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> References: <200910011857.31254.daniel@cacert.org> <18DE8E7FD48A1CCC884BD82F@lewes.staff.uscs.susx.ac.uk> Message-ID: On Oct 7, 2009, at 6:00 AM, Ian Eiloart wrote: > As far as I recall, Mailman removes DKIM signatures, and re-signs > messages. Close, but the spirit is right. Mailman does remove DKIM headers, if configured to do so via a site-wide option. The option is turned off by default. This comment in the configuration file is useful: # Some list posts and mail to the -owner address may contain DomainKey or # DomainKeys Identified Mail (DKIM) signature headers . # Various list transformations to the message such as adding a list header or # footer or scrubbing attachments or even reply-to munging can break these # signatures. It is generally felt that these signatures have value, even if # broken and even if the outgoing message is resigned. However, some sites # may wish to remove these headers by setting this to Yes. My own personal feeling is that Mailman should not be adding any DKIM headers, as this is the job of the outgoing MTA. Nor frankly should it be verifying DKIM headers, as that's the job of the incoming MTA. The optional removal of any existing DKIM headers a nod to practicality; without that cleansing step, ironically the mailing list appears more broken to people than with it. > You're saying that with ADSP, that's not adequate unless Mailman > first rewrites the "From:" address. Some lists are configured to do > this already, the question is what to do about those that don't. Ian and Stephen have eloquently stated opinions that I agree with. / Requiring/ munging of the From or Reply-to headers is not acceptable because you are trampling on long established valid use cases (not to mention violating standards in some cases). I don't like Reply-to munging, but Mailman does not prohibit it and it's a use-case that must be preserved. Similarly, anonymizing the From header is a necessary use case for other reasons, but it cannot be required. ISTM that Stephen has the most sensible solution when he proposes to sign the RFC 2369 headers. I still think that's something that would happen in the outgoing MTA instead of list manager. List-ID is the core identifying header for the list manager and a site administrator should be making assertions about it if they want to. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From daniel at cacert.org Sat Oct 10 04:29:14 2009 From: daniel at cacert.org (Daniel Black) Date: Sat, 10 Oct 2009 13:29:14 +1100 Subject: [Mailman-Developers] dkim and email list software In-Reply-To: <877hv4n5n9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <200910011857.31254.daniel@cacert.org> <200910091422.23721.daniel@cacert.org> <877hv4n5n9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <200910101329.19960.daniel@cacert.org> Hey Stephen and others, On Friday 09 October 2009 22:55:22 Stephen J. Turnbull wrote: > > Apart from the assertions of mailing list software developers I'm > > yet to receive a strong assertion from list operators or > > users. > > Er, do you think we write open source purely out of charity? We are > all operators and users ourselves. quite right. sorry. > (Non-developer) users and list > operators? See > http://wiki.list.org/display/DOC/From+field+displayed+by+Microsoft+Outlook > for what they think of the kind of display the munging you suggest > produces. (The point is it's a FAQ; they *do not* like it.) And can > you imagine what that will look like when combined with the munging > you suggest Mailman do to fake out ADSP? good point. Though seeing it suggests that maybe ADSP could cover Sender: and at least some users with MUA's that display things a little ugly could tell the difference between a spoofed email on a mailing list they subscribe to. > > Even less forthcoming is the reasons the lack of acceptability that > > could guide standards or implementations. > > 1. Spoofing authorship is what the phishers and the spammers do. > We're the good guys, remember? Note that the name of the standard > you are trying to promote here is *Author* Domain Signing Policy. > What that means is that the list's domain is claiming authorship > of the post. This is problematic in any number of ways. > > 2. Authorship information is lost, or at best obscured. You point > out that most MUAs don't present List-* headers. which I'm working on btw http://reviewboard.kde.org/r/1768/ > Well, they don't > present Sender or In-Reply-To either (except for Outlook). do you think MUAs should show Sender and/or Reply-To? if so would making mailman set these to the list address be acceptable for users? > You're > either in the From header, or the users don't know about it. > > 3. Sophisticated users filter on From. This breaks the filters > bigtime once, and makes them more fragile forever after. > > 4. It's ugly. Thank you for verbalising these four reasons. I accept all of these as reasons for not changing the From address and are unlikey to mention it again. > > there's a development cost that I'll consider contributing to but I'm > > not going to develop stuff that has no change of being accepted. > > I will consider writing patches for: > > 1. global dkim-friendly= true to disable list modifications parameters > > 2. From: rewriting > > 1. dkim-friendly is CAN-SPAM unfriendly. Specifically, best practice > (and maybe the law AIUI) requires you to put an unsubscribe notice > in somewhere. As you point out, the List-Unsubscribe header just > won't do.... This can probably be accounted for by DKIM l= tags (the signed length is..) on the sender's behalf and still allow additions of unsubscribe notices. If I account for this provision would it be considerable? (cut other information that I generally accept - thank you) > > A proposal for author domains to authorize third party lists is in > > development. http://mipassoc.org/pipermail/ietf-dkim/2009q4/012592.html > > > > It does place a large burden on author domains to deploy DNS records > > pre- presenting every list their user base send email too. > > So it certainly loses in my use case: I run support lists. I really > don't think someone whose editor has crashed and wants to know if they > can recover the data they were editing is going to wait for IT to > deploy DNS records before posting. true, though automated techniques may help http://tools.ietf.org/html/draft- kucherawy-dkim-reporting-05. I'll ask Murray about the future here. I'm a lot more included to support your LDSP proposal scoped with security concerns addressing forgery and reputation and/or a sender domain signing practices document. > > > The only real problem with this is getting the big ISPs to implement, > > > but that's nothing new. In fact if it's as easy as adding routines to > > > process the RFC 2369 + RFC 2919 set of headers "just like" ADSP > > > handles "From:", I bet most would be happy to sign on. > > > > So this is for mailing list that send though big ISPs that can't > > apply their own DKIM signatures? Not totally sure what you mean > > here though signing is the easy part compared to applying filtering > > on verification results. > > No, my mailing lists, and those like them, can deploy signatures and > DNS easily enough. The question about the big ISPs is will they > bother to do something to make things more comfortable for discussion > lists. Is this a matter of: 1. technology standardisation - (LDSP, DKIM Third-Party Authorization Label, Sender DSP) 2. deployment practice standardisation - http://tools.ietf.org/html/draft- ietf-dkim-deployment-08#section-6.3 3. deployment promotion - inclusion in, for example, mailman installation manual / site administrator documentation 4. ensuring DKIM verification tools development supports this. 5. some marketing / guides for ISPs with respect to DKIM There are other's battling in consideration of mailing lists (and are more sensible than me). http://mipassoc.org/pipermail/ietf-dkim/2009q4/012596.html Many would love to have your involvement there if you're interested. -- Daniel Black Infrastructure Administrator CAcert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From stephen at xemacs.org Sat Oct 10 14:09:54 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 10 Oct 2009 21:09:54 +0900 Subject: [Mailman-Developers] dkim and email list software In-Reply-To: <200910101329.19960.daniel@cacert.org> References: <200910011857.31254.daniel@cacert.org> <200910091422.23721.daniel@cacert.org> <877hv4n5n9.fsf@uwakimon.sk.tsukuba.ac.jp> <200910101329.19960.daniel@cacert.org> Message-ID: <87ljjjlab1.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Black writes: > quite right. sorry. I'm sorry for being sharp about it. You gave it the old college try, but similar proposals have been floated before. I was also in a bad mood for reasons that have nothing to do with Mailman Developers and not really to do with Mailman at all. The rest of the stuff below really isn't Mailman Developers-relevant, but I'm not sure if I can find time to accept your invitation to a more appropriate forum, so I'll post once more in hopes of seeding some memes. > good point. Though seeing it suggests that maybe ADSP could cover > Sender: and at least some users with MUA's that display things a > little ugly could tell the difference between a spoofed email on a > mailing list they subscribe to. I think users would probably not like that, or the proposals to display List-*, Sender, Reply-To and so on. I currently display a lot of unusual stuff (including In-Reply-To, References, X-Mailer, and User-Agent) but ironically none of those you suggest directly or indirectly. Most users, though, just want the usual: author, addressees, date. I think that in most cases the MUA can do a pretty good job of summarizing authenticity based on the DKIM signatures, according to a scale something like 1. *author* = author is authorized to send from her apparent domain 2. *list-verified* = list is authorized to send from its apparent domain *and* it authenticated the author 3. *list* = list is authorized to send from its apparent domain Users should by default be presented with *author* or not (boolean), because really anything less should not be trusted to be from your bank. Users who want the details could optionally be given the full scale. > > Well, they don't > > present Sender or In-Reply-To either (except for Outlook). > do you think MUAs should show Sender and/or Reply-To? > if so would making mailman set these to the list address be acceptable for > users? No, and no. Users really don't want to know those most of the time, and I think the kind of thing that people who don't browse the Received headers would be able to recognize probably can be reliably computed automatically, per the above list. It's certainly true that sometimes lists or individuals will get caught by that (eg, stephen at xemacs.org will almost never be ADSP authenticated, because I send from my university, not from an xemacs.org host). But that should be handled by a personal signature, not by the DNS, I think. Both Sender and Reply-To are originator headers. But, for example, I think it's reasonable for Mailman to munge Sender, since the user clearly has delegated the responsibility for transferring the message to Mailman, and any technical difficulties in distribution are probably best handled by Mailman. The only exception I can think of is the case where Mailman strips attachments by policy, and a recipient wants to request a copy. Normally From is a good place to ask for that. So really I don't see what value Sender has for spam-fighting. It could be set to any number of things, and interim hosts often have plausible reasons for changing it. Reply-To ... you don't want to mix into that one. See http://turnbull.sk.tsukuba.ac.jp/Blog/Software/ReplyToMungingConsideredEmCarefullyEm for something I wrote for a different venue just today. > > 1. dkim-friendly is CAN-SPAM unfriendly. Specifically, best practice > > (and maybe the law AIUI) requires you to put an unsubscribe notice > > in somewhere. As you point out, the List-Unsubscribe header just > > won't do.... > This can probably be accounted for by DKIM l= tags (the signed > length is..) on the sender's behalf and still allow additions of > unsubscribe notices. If I account for this provision would it be > considerable? Don't know. Many lists are configured to hack into HTML parts and add it *inside* the existing HTML BODY element, for example. Somebody more familiar with the use cases for editing the message body would have to answer for that. > true, though automated techniques may help > http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-05. I'll > ask Murray about the future here. Yeah. I worry about the security implications of something like that, though. Automatically munging the DNS on the basis of frequent requests from ordinary users is worrying. > I'm a lot more included to support your LDSP proposal scoped with security > concerns Oh, of course you need to scope it. However, ISTM you just map all the security concerns of ADSP to LDSP, then multiply "trust" by 0.5 (pick whatever figure you like; note that above I map it to 0 for the typical end user!) > > No, my mailing lists, and those like them, can deploy signatures and > > DNS easily enough. The question about the big ISPs is will they > > bother to do something to make things more comfortable for discussion > > lists. > > Is this a matter of: > 1. technology standardisation - (LDSP, DKIM Third-Party Authorization Label, > Sender DSP) > 2. deployment practice standardisation - http://tools.ietf.org/html/draft- > ietf-dkim-deployment-08#section-6.3 > 3. deployment promotion - inclusion in, for example, mailman installation > manual / site administrator documentation > 4. ensuring DKIM verification tools development supports this. > 5. some marketing / guides for ISPs with respect to DKIM All of the above, of course. > Many would love to have your involvement there if you're interested. I'm interested, the question is making the time..... From barry at python.org Mon Oct 12 20:18:24 2009 From: barry at python.org (Barry Warsaw) Date: Mon, 12 Oct 2009 14:18:24 -0400 Subject: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully* In-Reply-To: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> [Your original message probably didn't make it to mailman-developers since it was spelled "mailman-devel at python.org" -BAW] On Oct 10, 2009, at 4:19 AM, Stephen J. Turnbull wrote: > 2. A formal proposal of a new header field, Responses-To, whose sole > purpose is to allow mailing lists conforming to RFC 2369 to hint > to MUAs whether a reply or followup is usually appropriate on the > list. > > I've cross-posted to Mailman Developers because I'd like to solicit > the opinions of those folks about whether Mailman should implement > this draft RFC early in the process. Concrete proposals are a ways > off, though. Followup to Mailman Users, please. So a couple of things. I'm not opposed to implementing draft RFCs or even defacto proposals in Mailman as long as we label them experimental. IOW, should the RFC change, we'll obviously need to change Mailman to conform. A lot of email lore is just defacto standards and we already support many of them. We'll take them on a case-by-case basis, but Mailman should not blindly rule out supporting them. For the ones we like, Mailman support can go a long way to proving the feasibility and perhaps nudging others to support the proposals as well (see my Archived-At contents proposal). In general, I like Stephen's proposal as a way to help reduce the ambiguity in this very common workflow. I'll bikeshed on this detail: I think the header should be called Response-Precedence or maybe List- Response-Precedence. The 'List-*' prefix is evocative of RFC 2369 and since this is a list specific header, it should probably be prefixed as such. A counter argument would be that because it's the user and not the list that's making the value choice, it should not be a List-* header. Response-Precedence is evocative of the defacto Precedence header, and it makes some sense to me because you're specifying the precedence of where responses should go, based on the conditional you posted. *-To: headers feel more like they should contain an address but this has a limited vocabulary, as does Precedence, so I like it not being a *-To header. As for going the RFC route, I think it's not a bad idea, but I have no idea how much work is involved. ;) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From stephen at xemacs.org Mon Oct 12 21:40:20 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 13 Oct 2009 04:40:20 +0900 Subject: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully* In-Reply-To: <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> References: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> Message-ID: <87hbu4ieor.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > [Your original message probably didn't make it to mailman-developers > since it was spelled "mailman-devel at python.org" -BAW] Thanks. > In general, I like Stephen's proposal as a way to help reduce the > ambiguity in this very common workflow. I'll bikeshed on this detail: > I think the header should be called Response-Precedence or maybe List- > Response-Precedence. Fine with me, either way. I waffled on the name anyway. > The 'List-*' prefix is evocative of RFC 2369 and since this is a list > specific header, it should probably be prefixed as such. It's not just list-specific, it's specifically for the use of lists, not users. As such it seems reasonable to me that it would be prefixed "List-". > As for going the RFC route, I think it's not a bad idea, but I have no > idea how much work is involved. ;) For anything related to Reply-To/Mail-Followup-To, it's probably a pretty long road. I wouldn't mind having an RFC in my cv, though. (It is *not* going to List Domain Signing Policy, though, that can of worms I'll feed to the fish.) From barry at python.org Mon Oct 12 21:51:00 2009 From: barry at python.org (Barry Warsaw) Date: Mon, 12 Oct 2009 15:51:00 -0400 Subject: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully* In-Reply-To: <87hbu4ieor.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> <87hbu4ieor.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Oct 12, 2009, at 3:40 PM, Stephen J. Turnbull wrote: > It's not just list-specific, it's specifically for the use of lists, > not users. As such it seems reasonable to me that it would be > prefixed "List-". > >> As for going the RFC route, I think it's not a bad idea, but I have >> no >> idea how much work is involved. ;) > > For anything related to Reply-To/Mail-Followup-To, it's probably a > pretty long road. I wouldn't mind having an RFC in my cv, though. > (It is *not* going to List Domain Signing Policy, though, that can of > worms I'll feed to the fish.) Perhaps a good place to start is to write up a draft on wiki.list.org? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From stephen at xemacs.org Mon Oct 12 22:46:15 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 13 Oct 2009 05:46:15 +0900 Subject: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully* In-Reply-To: References: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> <87hbu4ieor.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87bpkcibmw.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > Perhaps a good place to start is to write up a draft on > wiki.list.org? Will do. Is there a good place to put it? From barry at python.org Mon Oct 12 23:04:42 2009 From: barry at python.org (Barry Warsaw) Date: Mon, 12 Oct 2009 17:04:42 -0400 Subject: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully* In-Reply-To: <87bpkcibmw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> <87hbu4ieor.fsf@uwakimon.sk.tsukuba.ac.jp> <87bpkcibmw.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <06FCEDA4-98F9-4ADE-A341-F7F841275B67@python.org> On Oct 12, 2009, at 4:46 PM, Stephen J. Turnbull wrote: > Barry Warsaw writes: > >> Perhaps a good place to start is to write up a draft on >> wiki.list.org? > > Will do. Is there a good place to put it? I would start by putting it under Initiatives here: http://wiki.list.org/display/DEV/Home But really, we should have a separate page/section for RFCs/standards we're proposing. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From stephen at xemacs.org Tue Oct 13 06:37:48 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 13 Oct 2009 13:37:48 +0900 Subject: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully* In-Reply-To: <06FCEDA4-98F9-4ADE-A341-F7F841275B67@python.org> References: <87skdrlkzn.fsf@uwakimon.sk.tsukuba.ac.jp> <0EE4AD5C-3BB0-4C9E-8B35-40004BD3C3F6@python.org> <87hbu4ieor.fsf@uwakimon.sk.tsukuba.ac.jp> <87bpkcibmw.fsf@uwakimon.sk.tsukuba.ac.jp> <06FCEDA4-98F9-4ADE-A341-F7F841275B67@python.org> Message-ID: <87ws2zhpsz.fsf@uwakimon.sk.tsukuba.ac.jp> Since we're getting concrete here, redirecting to Mailman Developers. Barry Warsaw writes: > On Oct 12, 2009, at 4:46 PM, Stephen J. Turnbull wrote: > I would start by putting it under Initiatives here: > > http://wiki.list.org/display/DEV/Home > > But really, we should have a separate page/section for RFCs/standards > we're proposing. It will be a couple of days (Oct 15 is tax day for US expats), but I'll do that, too (pulling in the stuff I mentioned in that long post on Email-SIG), if you think it makes sense. The idea would be to have a top page "Conformance Statements for RFCs, Standards, and Conventions", it would have a list by standards document: ---------------------------------------------------------------- Conformance Statements for RFCs, Standards, and Conventions =========================================================== - `RFC 1149`__ ("IP Packet Transport via Avian Carrier") - `List Response Precedence`__ ("Reply-To munging considered carefully") __ RFC1149Conformance __ ListResponsePrecedenceConformance ---------------------------------------------------------------- The linked pages would have structure: ---------------------------------------------------------------- Draft RFC: List Response Precedence Conformance =============================================== Standard: `Draft RFC: List Response Precedence`__ Status of Implementation: verified [or "assigned: BAW" or "open" or "implementation not complete"] Date of last change: 1066 October 14 __ DraftRFCListResponsePrecedence [this would reside on our wiki, the link for RFC 1149 would point to an IETF resource] Tasks ----- Check for "Mail-Followup-To" header field: implemented and tested. Check for "List-Response-Precedence" header field: design blocked pending completion of draft RFC. Option in web interface: not started. ---------------------------------------------------------------- Sound good? Or is this too anal-retentive? Few would have to be so detailed, but if there are things we decide not to implement, it would be good to have this as a reference documenting that decision. From dnovotny at redhat.com Tue Oct 13 13:56:57 2009 From: dnovotny at redhat.com (Daniel Novotny) Date: Tue, 13 Oct 2009 07:56:57 -0400 (EDT) Subject: [Mailman-Developers] a patch for French localization In-Reply-To: <1380570565.78131255434987927.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1063009550.78231255435017838.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello, the python config file obtained from "config_list -o" has localization problem. When the preferred_langage is set to french 'fr', the # -*- coding: %(charset)s -*- \n" header is translated to "# -*- codage : %(charset)s -*-\n", that generates an unparseable configuration file. so IMO, it's better to leave this msgid untranslated (#: bin/config_list:117) in messages/fr/LC_MESSAGES/mailman.po Patch attached. References: https://bugzilla.redhat.com/show_bug.cgi?id=528492 the Fedora bug report best regards, Daniel Novotny, Red Hat inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman-2.1.12-codage.patch Type: text/x-patch Size: 563 bytes Desc: not available URL: From mark at msapiro.net Tue Oct 13 17:00:06 2009 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 13 Oct 2009 08:00:06 -0700 Subject: [Mailman-Developers] a patch for French localization In-Reply-To: <1063009550.78231255435017838.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Daniel Novotny wrote: > >the python config file obtained from "config_list -o" has localization problem. >When the preferred_langage is set to french 'fr', the # -*- coding: %(charset)s >-*- \n" header is translated to "# -*- codage : %(charset)s -*-\n", that >generates an unparseable configuration file. A similar issue exists with Spanish 'es' and Hebrew 'he'. I'm not sure how serious this is since the only non-ascii in the file is in comments and string literals. In fact, several other translations drop the "coding" line entirely. I don't understand how this would render the file "unparseable" when used as input to python or config_list. However, it is incorrect to translate "coding" to another language, so I will fix these three. Note also that there is a problem with the patch. There should be no space between 'coding' and the following colon. Ref -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From john at postcompanies.com Mon Oct 12 18:13:11 2009 From: john at postcompanies.com (John Goodell) Date: Mon, 12 Oct 2009 12:13:11 -0400 Subject: [Mailman-Developers] Looking for a mailman developer to hire In-Reply-To: References: Message-ID: <492F6ED75AD54367B98E1812BD7FBA1E@JPG> Am looking for an experienced mailman developer to hire for a few small installations/upgrade to our deployment, including: personalized header/footer fields (using qmail injection), attachment issue for HTML messages, and a few others. Thanks, John From john at postcompanies.com Mon Oct 12 18:13:52 2009 From: john at postcompanies.com (John Goodell) Date: Mon, 12 Oct 2009 12:13:52 -0400 Subject: [Mailman-Developers] Looking for a mailman developer to hire In-Reply-To: References: Message-ID: <7467E18D1B414FF1AE43277C6C5F83B1@JPG> Am looking for an experienced mailman developer to hire for a few small installations/upgrade to our deployment, including: personalized header/footer fields (using qmail injection), attachment issue for HTML messages, and a few others. Thanks, John From mbt at zest.trausch.us Wed Oct 14 00:56:59 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Tue, 13 Oct 2009 18:56:59 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1255474619.16706.15.camel@zest.trausch.us> Note, I am not subscribed to mailman-developers at python.org, so this message may or may not get through to that list. I did CC everyone interested so far, though (I think), in this subthread. On Tue, 2009-10-13 at 16:03 +0900, Stephen J. Turnbull wrote: > Reply-To set to me. Please verify that your replies are going to the > intended place. Indeed, Ctrl+R does reply to you. > Michael B. Trausch writes: > > In any case, it's off-topic, and unless others here are interested > > in the discussion, or there's a chance that the ML config would be > > changed, it's probably best just to drop it altogether. > > I'm not sure where discussion will take place. Not here, possibly > Mailman Developers ML, most likely wiki.list.org. Drop me a line and > I'll make sure that you're notified about the new venue. It will > probably be Saturday or so. I assume that since we've already gone there, that's where it'll be. I assume I'll know shortly after I hit C-RET if I need to be subscribed there, too... > As long as I'm here, let me respond. > > > I've seen that argument before; it's fine, but the ideal situation is > > impossible to achieve (some form of complete consistency amongst all > > mailing lists globally). > > The draft RFC admits that. It's not a panacea, it's a path forward. > > The problem to date, AFAICT from the litter on the path to RFC 2822, > is that a lot of people want a way to indicate that responses SHOULD > go to the list (of course you can't *force* them to go to the list). > They have insisted on coopting Reply-To and Mail-Followup-To for that > purpose because they are existing headers that many MUAs already > respect. This breaks their usage as defined in the RFCs, so the > cooler heads have refused to sanction such usage. They are for the > *author* to indicate where personal replies and public discussion, > respectively, should be conducted. > > The upshot is that there is no RFC-sanctioned way for a list to say > "please respond here", and no way at all that doesn't usurp *both* the > author's and the receiver's options. The best way to do this far simpler, I think: 1. Mailer software should reply to From or Reply-To as currently. 2. ML software should set Reply-To _UNLESS_ there was _already_ a Reply-To. Then, Reply-To isn't truly broken, because the author has control over it still, and it just defaults to the list. This manages to make things work 95% of the time for 95% of the people. I know that people far less technical than myself expect the behavior above. I don't know about ML's and whether or not they'll respect and author-set Reply-To if one is set in the ML configuration, but I've never tried, either; I do know that of the lists I'm on, the Bazaar ML and one other one (don't remember right now which one) are the only two that actually don't set Reply-To. Now, RFC 2822 says that From, Sender and Reply-To are "originator fields". It also says this: > > The intention is to fix that. I already have agreement in principle > from the Mailman boss to implement for that list manager. I will > provide an implementation of my algorithm that can be used in Emacs > MUAs. I'm sure I can get VM and MH-E to adopt it, and almost sure > Gnus will. The KDE KMail guy has expressed interest. Both seemed to > think my proposal is actually novel, but I certainly will check the > IETF archives in order to frame it properly in existing discussion. > > > On the topic of the discussion, though, what is better for all is a > > default behavior that is correct, say, 95% of the time for 95% of the > > people. > > My algorithm gives that by default. The draft RFC gives a way for a > mailing list to either insist on public followup or to strongly > discourage it. -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ ?The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.? ?Michelangelo From mbt at zest.trausch.us Wed Oct 14 01:15:02 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Tue, 13 Oct 2009 19:15:02 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1255475702.16706.33.camel@zest.trausch.us> UGH. I hit Send by accident, going for the menu bar. I hate my mouse. Sorry for the dup. Note, I am not subscribed to mailman-developers at python.org, so this message may or may not get through to that list. I did CC everyone interested so far, though (I think), in this subthread. On Tue, 2009-10-13 at 16:03 +0900, Stephen J. Turnbull wrote: > Reply-To set to me. Please verify that your replies are going to the > intended place. Indeed, Ctrl+R does reply to you. > Michael B. Trausch writes: > > In any case, it's off-topic, and unless others here are interested > > in the discussion, or there's a chance that the ML config would be > > changed, it's probably best just to drop it altogether. > > I'm not sure where discussion will take place. Not here, possibly > Mailman Developers ML, most likely wiki.list.org. Drop me a line and > I'll make sure that you're notified about the new venue. It will > probably be Saturday or so. I assume that since we've already gone there, that's where it'll be. I assume I'll know shortly after I hit C-RET if I need to be subscribed there, too... > As long as I'm here, let me respond. > > > I've seen that argument before; it's fine, but the ideal situation is > > impossible to achieve (some form of complete consistency amongst all > > mailing lists globally). > > The draft RFC admits that. It's not a panacea, it's a path forward. > > The problem to date, AFAICT from the litter on the path to RFC 2822, > is that a lot of people want a way to indicate that responses SHOULD > go to the list (of course you can't *force* them to go to the list). > They have insisted on coopting Reply-To and Mail-Followup-To for that > purpose because they are existing headers that many MUAs already > respect. This breaks their usage as defined in the RFCs, so the > cooler heads have refused to sanction such usage. They are for the > *author* to indicate where personal replies and public discussion, > respectively, should be conducted. > > The upshot is that there is no RFC-sanctioned way for a list to say > "please respond here", and no way at all that doesn't usurp *both* the > author's and the receiver's options. The best way to do this far simpler, I think: 1. Mailer software should reply to From or Reply-To as currently. 2. ML software should set Reply-To _UNLESS_ there was _already_ a Reply-To. Then, Reply-To isn't truly broken, because the author has control over it still, and it just defaults to the list. This manages to make things work 95% of the time for 95% of the people. I know that people far less technical than myself expect the behavior above. I don't know about ML's and whether or not they'll respect and author-set Reply-To if one is set in the ML configuration, but I've never tried, either; I do know that of the lists I'm on, the Bazaar ML and one other one (don't remember right now which one) are the only two that actually don't set Reply-To. Now, RFC 2822 says that From, Sender and Reply-To are "originator fields". It also says this: When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent. AFAIC, _this_ author wants replies to his posts to go to a ML unless he says otherwise. That would tie with #2 above, and it seems to me to be a quite reasonable default. As things currently sit, the default would seem to be "reply to me, unless I say otherwise," which doesn't make sense in the context of an ML. So, this is a bit of a higher-level discussion than the RFCs really provide for. Further, RFC 2822 doesn't prohibit mailing lists from setting Reply-To, and discussion about that would seem to me to be splitting hairs as to where the author suggests posts go in the first place. Your page says that it applies to the originator of the message, but the RFC does not say that; it says that it's an originator header, and from the POV of my Inbox, that's exactly where the mail comes from (e.g., the message comes from human A sending message A, and then the ML server receives message A and becomes the new origin, sending out messages A(1), A(2), ..., A(n)). IOW, reply-to only makes sense in its default (none, that is, reply to from) in interpersonal communications or self-made "distribution lists" where From == To and the recipients are all Bcc'd. I would say that if ML software _always_ overrides reply-to, even when the author explicitly provided one, then that is broken. And that does leave the odd corner case of "My outbound origin is user at machine.example.org but I want inbound mail to go to user at example.org" unhandled, but I think that is such a rare case that they would expect misdirected mails in that event. > The intention is to fix that. I already have agreement in principle > from the Mailman boss to implement for that list manager. I will > provide an implementation of my algorithm that can be used in Emacs > MUAs. I'm sure I can get VM and MH-E to adopt it, and almost sure > Gnus will. The KDE KMail guy has expressed interest. Both seemed to > think my proposal is actually novel, but I certainly will check the > IETF archives in order to frame it properly in existing discussion. > > > On the topic of the discussion, though, what is better for all is a > > default behavior that is correct, say, 95% of the time for 95% of the > > people. > > My algorithm gives that by default. The draft RFC gives a way for a > mailing list to either insist on public followup or to strongly > discourage it. In the event of: * user reports problem to ML * admin asks for info (s)he knows to be sensitive * user replies to ML This is easily fixed by the admin explicitly setting reply-to for that single message. However, reply-to becomes meaningless in such a situation where admin x always sets the header (as in the odd case I mentioned above), again because of the misdirected-reply problem. So, in the end, I think that the algorithm you mentioned is a good step in the right direction, sure. But I think the ultimate solution is even simpler than that: Use the reply-to standard header to make it possible for users to "do what they mean", by setting a default and using it when a message comes in that _doesn't_ have a reply-to set on its header and is intended to be posted to the list. Even better, this eliminates the problem of: I post message A without reply-to: To: ml at example.org From: mbt at zest.trausch.us Someone responds with message B and hits reply-all, also without reply-to: To: mbt at zest.trausch.us Cc: ml at example.org From: user at example.org And then I don't get a message with a List-Post header _at all_. That is one failing that your algorithm cannot fix, unless the ML sends its second copy (and most MLs are configured not to do so, because users find it inconvenient). --- Mike -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ ?The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.? ?Michelangelo From stephen at xemacs.org Wed Oct 14 05:55:55 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 14 Oct 2009 12:55:55 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255475702.16706.33.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> Message-ID: <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> Michael B. Trausch writes: [This was me, stephen, but the attribution was dropped:] > > The upshot is that there is no RFC-sanctioned way for a list to say > > "please respond here", and no way at all that doesn't usurp *both* the > > author's and the receiver's options. > > The best way to do this far simpler, I think: > > 1. Mailer software should reply to From or Reply-To as currently. > 2. ML software should set Reply-To _UNLESS_ there was _already_ a > Reply-To. Then, Reply-To isn't truly broken, because the author > has control over it still, and it just defaults to the list. Reply-To still is truly broken. The author wants personal replies to go to her, but now they go to the list. The recipient must *specifically avoid reply-to-author* in order to reply to the author. This is so Orwellian. > IOW, reply-to only makes sense in its default (none, that is, reply to > from) in interpersonal communications or self-made "distribution lists" > where From == To and the recipients are all Bcc'd. Stop deprecating use cases that you don't use. They exist, are important to their users, and what you are advocating is tyranny of the majority. Not on our Internet, please. I have no objection to the functionality you want, but I take *strong* exception to having the very useful Reply-To field *hijacked* so that you don't need to wait for my proposal to be implemented.[1] > So, in the end, I think that the algorithm you mentioned is a good step > in the right direction, sure. But I think the ultimate solution is even > simpler than that: Except that it is *not* an ultimate solution, because the function of the Reply-To field is lost in important cases. A new Reply-To field that third parties are prohibited from munging would have to be defined. Why do that when we already have one? Footnotes: [1] The problem of the wrong dupe being eliminated is *not* a problem with Reply-To, although it may be made more frequent. It's simply the case that if access to the List-Post field in every message is desired, the mailing *cannot* do dupe elimination. *Not* *at* *all*. Your use case here is broken. Badly. From john at postcompanies.com Wed Oct 14 05:51:53 2009 From: john at postcompanies.com (John Goodell) Date: Tue, 13 Oct 2009 23:51:53 -0400 Subject: [Mailman-Developers] Support for multiple domains in mailman3 Message-ID: Hello - I hope this is an appropriate place to post this question - will mailman 3 support multiple domain installations on one server? That is, currently a single mailman installation on a box can be setup to distribute to 1 domain name at a time - will we be able to run multiple domains on a single installation (on 1 server)? Thanks, John From mbt at zest.trausch.us Wed Oct 14 07:35:16 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Wed, 14 Oct 2009 01:35:16 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1255498516.13356.69.camel@zest.trausch.us> On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote: > Michael B. Trausch writes: > > [This was me, stephen, but the attribution was dropped:] The attribution was _not_ dropped, it was at the top of the message in standard inline-reply fashion. You may want to double check the message to verify that: http://www.mail-archive.com/mailman-developers% 40python.org/msg11590.html Short link to the same resource, in case of breakage: http://is.gd/4iD4o > > > The upshot is that there is no RFC-sanctioned way for a list to say > > > "please respond here", and no way at all that doesn't usurp *both* the > > > author's and the receiver's options. > > > > The best way to do this far simpler, I think: > > > > 1. Mailer software should reply to From or Reply-To as currently. > > 2. ML software should set Reply-To _UNLESS_ there was _already_ a > > Reply-To. Then, Reply-To isn't truly broken, because the author > > has control over it still, and it just defaults to the list. > > Reply-To still is truly broken. The author wants personal replies to > go to her, but now they go to the list. The recipient must > *specifically avoid reply-to-author* in order to reply to the author. > This is so Orwellian. Permit me to rephrase so that you understand what I said: There are two major uses of email, discounting automatically generated messages, corporate crap and spam: email from one person or to one person or a group of people, and email from one person to a mailing list (presumably with people on it). Whether the emails are in a personal, hobbyist, collegiate, educational, or professional context, the patterns are largely the same. In both events, 95+% of the time, there is no reply-to header attached by the authors MUA. However, the primary use-case for a mailing list is _group_ _discussion_. Or at least, so I thought. Call me silly, but if it's not meant to be group discussion as the primary role, maybe mailing lists should stop using server software and become ad-hoc, old boys' club style, personally shared and replicated distribution lists, nothing more. Being that is the case, and that is what users of mailing lists _expect_, it is reasonable to assume that the way reply-to is handled would be thus: * I send an email to the mailing list to start a thread of discussion. I send no reply-to header on the message, so the list processing software appends one redirecting replies to the group. This facilitates group discussion. It's not Orwellian, it's common sense---if, of course, we make the assumption that mailing lists are for, you know, group discussion and not private communication. If I want to communicate privately with someone, I won't be sending the mail to a mailing list; if I need to communicate with someone who is on a ML privately, and I don't have their address, that's what ML archives are for (or, sending a mail to the ML to ping them, or searching my own archives, if the public archives have that information stripped). * During the course of the thread, it becomes clear that some sensitive information must be sent (to address your use case from your Web page from earlier in this thread). That's totally not a problem: The person asking for the sensitive information simply adds a reply-to header to their outbound message. The mailing list _sees_ this reply-to header, and then refuses to replace it, transform it, or supercede it, because the rule SHOULD be "Only add a reply-to to a message if it does not have one already." I don't know if there is _any_ software that does this currently out there, but if there isn't, that's something that is at least easily fixed in any system even if it's horribly designed. It translates to nothing more than a single if statement in code. It'd be trivial for users of non-proprietary systems to adopt even if they don't want to upgrade their mailing list software. Now, there is of course an alternative mechanism that could be used to meet the same need: Have a header, say, X-List-Please-Reply-To-List, that a MUA could add in a generic fashion to all mail messages. That could signal to the list processing software, "Yes, Please, I WANT people replying to my messages to reply to the list." However, I don't see that as at all likely to occur. For me to fit into your suggested solution, I'd have to wait for both your algorithm to be ubiquitous in MUA software _and_ all mailing list software to be upgraded or replaced to make the headers it depends on to be ubiquitous. Still, to get truly sane behavior, I'd have to use Alpine. Why? The MUA _can_ do what I meant, and it can do it _easily_. There is _nothing_ that will fix the situation of no-duplicate-posts and the associated "Oops, I sent that to you and I meant to send it to the list as well," unless the MUA does one of the following (either by default, or by configuration): - Uses "reply to all" as the default behavior (config item), or - Asks you what you want to do when there are multiple recipients to the message that you're replying to (could be a sane default _and_ a config item) Alpine does the latter by default. I have used no MUA that does the former (that I am aware of; some of them perhaps did, but I've tried many and quickly fled any that are buggy in areas that I cannot fix and impact my usage patterns), and I don't know of any other ones that behave the way Alpine does. If Alpine fit better into my workflow overall, I'd use _that_ instead, solely for that single feature. Why? Because while it may not be smart enough to do what I meant for it to do, it is smart enough to recognize that fact and _ask_ what I mean for it to do. Unfortunately, most MUA software seems to take as an axiom that humans are infallible and will always do The Right Thing. Call me silly, but I have software to help me to do that in many ways; if I didn't want that, I'd type my messages directly into a socket, speak SMTP myself, and likely do so using an 8088 with DOS running a tiny network stack and with frequent calls to INT 0x21 and INT 0x60. Thankfully, that's not required, nor do I desire it. > > IOW, reply-to only makes sense in its default (none, that is, reply to > > from) in interpersonal communications or self-made "distribution lists" > > where From == To and the recipients are all Bcc'd. > > Stop deprecating use cases that you don't use. They exist, are > important to their users, and what you are advocating is tyranny of > the majority. Not on our Internet, please. I didn't deprecate _anything_. I'm going to give you the benefit of the doubt and assume that you must have had a really bad day or something.* > I have no objection to the functionality you want, but I take *strong* > exception to having the very useful Reply-To field *hijacked* so that > you don't need to wait for my proposal to be implemented.[1] > > > So, in the end, I think that the algorithm you mentioned is a good step > > in the right direction, sure. But I think the ultimate solution is even > > simpler than that: > > Except that it is *not* an ultimate solution, because the function of > the Reply-To field is lost in important cases. A new Reply-To field > that third parties are prohibited from munging would have to be > defined. Why do that when we already have one? Citation, please? I already quoted the part of RFC 2822 that shows that semantically speaking your assertion is incorrect. If there is an RFC that supersedes the definitions of RFC 2822, I'd like to see it. At present, I am not aware of one. (Further, if there is additional clarification that I've missed in my readings of RFC 2822, I'd like a pointer to that, as well; I've already read it once today, maybe I'll review it again later for things I missed in today's reading.) In my (admittedly, limited in terms of global and topical coverage) personal experience, _most_ mailing lists are poorly configured on the extreme of users not being able to specify a reply-to at all, because the reply-to is stripped and subsequently replaced by the mailing list software. Clearly, this is _bad_. Is it wrong? Not according to RFC 2822, because the mailing list processor is the logical origin of a message and thus it is clear to send the header---or not---as it sees fit. However, what sparked this thread was a practical concern regarding a very common usage pattern, not a concern that everything be 100% idealistic and precisely fit some standard as interpreted by random person X. In other words, what we're talking about is left---according to the ambiguous text in RFC 2822---as an implementation detail of mailing list processing software. > Footnotes: > [1] The problem of the wrong dupe being eliminated is *not* a problem > with Reply-To, although it may be made more frequent. It's simply the > case that if access to the List-Post field in every message is > desired, the mailing *cannot* do dupe elimination. *Not* *at* *all*. > Your use case here is broken. Badly. I never *said* it was a problem with reply-to. I _did_ say that by adopting a sane default (but able to be overrode by the sender _simply_ by using the header him/herself) value is a practical thing to do, is useful, and fits 95% of the people's workflows, 95% of the time---maybe more, maybe less, but I don't believe I'm terribly far outside of the ballpark. In _ANY_ system there is going to be exceptions, but guess what? That's because we are human, and no matter how pedantic or technical we are, we're going to screw up occasionally. If this conversation is going to degrade into slinging and retaliation based on emotion-provoking arguments instead of grounded ones, I think it's best that it stops here. If you want to talk about 1984, there's a place and time for that; if you want to overlook details, I'm sure there's one for that, too. I was talking about a practical matter, and it was just a comment (regarding my MUA, which I am _well_ aware could behave better, and I simply do _not_ have the time to make that happen right now). It wasn't supposed to blow up into a huge argument of religion and who can interpret RFCs more conservatively or liberally than the other. Have a better day tomorrow,* Mike * My wife seems to think that I come off sarcastic in those statements. In case that is how you read it, allow me to assure you, that is not my intent. -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ ?The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.? ?Michelangelo From stephen at xemacs.org Wed Oct 14 09:53:27 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 14 Oct 2009 16:53:27 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255498516.13356.69.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> Message-ID: <87y6nefm2w.fsf@uwakimon.sk.tsukuba.ac.jp> Michael B. Trausch writes: > Permit me to rephrase so that you understand what I said: I understand what you said. You are not responding to what I said, except emotionally. Stripped of emotional language, the fact is that there are use cases for Reply-To which Reply-To munging overrides. The fact is that the RFCs have consistently, despite *decades* of argument along the lines you proposed, reserved use of the Reply-To field to the originator, who is clearly the author(s) or agent of same. (Otherwise Message-ID-munging would be similarly appropriate.) The fact is that your proposal takes the right to use the Reply-To field *or have the From field used /automatically/ as the destination for personal replies* in all circumstances, a right clearly delegated to the originator by the RFCs, away in *some* circumstances, for the convenience of third parties. Please respond to those facts rather than assuming I don't understand what you're talking about. From mbt at zest.trausch.us Wed Oct 14 10:19:19 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Wed, 14 Oct 2009 04:19:19 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <20091014063026.GK14800@benfinney.id.au> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> Message-ID: <1255508359.13356.170.camel@zest.trausch.us> On Wed, 2009-10-14 at 17:30 +1100, Ben Finney wrote: > On 14-Oct-2009, Michael B. Trausch wrote: > > On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote: > > > Reply-To still is truly broken. The author wants personal replies > > > to go to her, but now they go to the list. The recipient must > > > *specifically avoid reply-to-author* in order to reply to the > > > author. This is so Orwellian. > > > > Permit me to rephrase so that you understand what I said: > > > > There are two major uses of email [for actual discussion]: email > > from one person or to one person or a group of people, and email > > from one person to a mailing list (presumably with people on it). > > I can't parse the above into two; I assume there's a mistake, and that > you meant ?email from one person to one or more people, and email from > one person to a mailing list?. If you meant something else, I'm not > seeing it. No, that's exactly what I meant; I'm not sure where the mis-read is happening, because what you said and what I said are exactly the same. > > > However, the primary use-case for a mailing list is _group_ > > _discussion_. > > Yes. This majority use, though, should not make it more difficult to > use ?reply to author?. I think that there are some differences in base assumptions here. The initial comment that started this whole regrettable mess was that my software needs to do what I mean. I'm utterly _sick_ of the inconsistency and it's becoming a real drag on getting things done, because of late I have to wonder if I really sent the blasted messages correctly. We have: * MLs that allow a MUA to click reply and _just_ reply to the ML, and * MLs that require "reply all" instead, and instead of sending _one_ message in threading context, send N number of messages where N is however many people are listed in various headers. Now, _this_ is where the situation is _bad_. It's _awful_. If every single ML worked in precisely the same way, there would be _zero_ issues. Yes, some failure modes would exist that wouldn't in the other one and whatever, but at the very least, the modes of operation would be _consistent_. In such a world, the idea of "do what I mean" is something that we can then teach our systems to do for us. Presently, it is not. Now, we have in the first category, the "click reply to reply to the message" lists. These lists save bandwidth and make things easy for the _vast_ majority of use cases by not requiring the user to track nearly anything. They're automatic, and they Just Work. There is, of course, the potential downside of someone sending information to the list that they did not intend to do so. That is certainly a valid risk. Is it annoying? Yes. Could it potentially be disastrous? Yes, though most often not because with these types of lists most risk is easily mitigated because it's caught early enough to have something done about it through one of many channels. On the other hand, we have lists that don't do that. And for those, we must have MUAs send multiple messages; at minimum, two: one to the author of the message being replied to, and one as a Cc: to the mailing list. This introduces failure modes that are _consistently_ annoying and not easily automatically dealt with, ranging from issues like broken mail filters (because some lists don't have a [list] appendage in the subject and thus one must filter on a List-* header, which is not present when you are in To: or Cc: _and_ the message is sent to the ML), to not posting to the list at all. And I'm far from the only one that has encountered these frustrations recently on various MLs. How can these be handled? Again, let's look at the first type of list. There is a possible automatic solution, and (more likely to be used on lists where it could be a persistent issue) a less automatic means employing convention. The automatic solution would be MUA-side, not ML-server side, in that MUA software would prompt the user ("How do you wish to reply? [To List] [To Sender] [To All]"). The user could choose one to be the default if desired, and then the burden of responsibility is (rightly) on them. This is similar to what Alpine implements, though better. There are a couple of other automatic solutions, as well, which I will only mention in brief, because I don't think anyone really cares about them: * A List-Hold-For MUA header with a sane maximum value (maybe 1800 seconds). ML could send a reply that users could act on (meant to, didn't mean to) and if it times out based on the header, the ML would go ahead and post the message. A Web UI could also work. * A List-No-Archive MUA header, which clients could set by default if desired which would confine leakages to recipients and not archives or mail/nntp gateways, though the downsides of that would be obvious. * A List-User-Confirmed MUA header that could be set by user agents in combination with a prompt from above, and the ML server could send an autoreply to a message with L-U-C not set and ask "Did you mean to do that," with a timeout of 1 day or so and a default action of not posting the message if no action is taken before its timeout. * A List-Never MUA header that would cause ML software to reject posts, combined with an autoreply to confirm that they really wanted to do that, like ML software could do in the absence of a L-U-C header. MUA software could set/not set this option by configuration items. * Any of the sorts of ideas above that generate an autoreply would be useful with state: The ML server could add a List-AutoReply header that the MUA could use to present a better UI to the user instead of displaying the message, with List-AutoReply-Approve and List-AutoReply-Deny headers specifying a URL that can be handled by the MUA software (or passed to an external program, say a Web browser) when the user wants to approve or deny a post. Autoreplies would also have the original message as-would-be-posted attached. There are, of course, other variations on any of those ideas that could be put into practical use. The best solutions would depend on zero MUA features, while providing more featureful MUA software with the ability to better handle many of the situations. Autoreplies in a knowledgeable MUA could be hidden entirely and just presented to the user as UI dialogs or windows or similar. Another solution would be to have a dedicated address for certain types of sensitive email. Say, an email address for a team or private, non-archived mailing list that accepts posts from non-subscribers and is handled by people who are responsible and won't leak things. Then, when someone says, "Please send the details to private-email at example.org", it's clear what is being asked and where it is to be sent. After all, we _can_ assume that humans are, while imperfect, capable of being responsible for their actions and reading the messages that are sent to them. If we cannot make that assumption, then there really isn't much point to a messaging system of any sort, much less a widescale one like email, is there? In the second type of list, sure you have private replies by default, but you then make _everyone_ on the list have to reply-all or whatever. Additionally, you make _everyone_ on the list try to find ways to filter their list posts and replies into a folder, and many MUAs are not featureful enough to try to compare incoming messages with a references or in-reply-to header to previous messages for the mailing list, and even so, it'd be error prone (what if the referenced messages are deleted?) and kludgey. Are such lists useful? Of course, but they are much more work for everyone involved when compared to the simplicity of the other type of list. Because it is certain that not 100% of the mail will pass through the mail server, no automatic features can be used to help the user out either on the ML server side or on the MUA client side, because the MUA does not have enough information to properly do what the user wants it to do at least some of the time. > As has no doubt already been pointed out in this discussion, the > failure modes are wildly unbalanced: > > * ?Whoops, I sent a message intended for the whole list instead as a > reply to the author. Oh well, I'll re-send the reply to the list.? > Annoying for the two people involved, but no permanent harm done. > > * ?Whoops, I sent a message intended only for the author instead as a > reply to the whole list.? Completely the opposite of what ?reply to > author? is supposed to do, and unrecoverable. What MUA are you using that has a "Reply to Author" option? Most that I know have "Reply" (undecorated) or "Reply to Sender" which could be read one of two ways. While "Reply to Author" is always 100% unambiguous, I don't know that many MUAs advertise their reply that way. Evolution, for example, presents the man UI as simply "Reply" in the context of a message; in the menu it shows "Reply to Sender". Poll 100 end-user types (non-technical people) and you'll likely find 3 answers to the question "What does reply to sender mean in the context of a mailing list post?", with no way to deterministically predict what the percentages are on that.* > > * I send an email to the mailing list to start a thread of > > discussion. I send no reply-to header on the message, so the list > > processing software appends one redirecting replies to the group. > > It directs the ?reply to author? replies to the group, despite the > intent of the respondent. A recipe for disaster, as has been > demonstrated countless times over the years. Though, as I mentioned above, there are automatic ways to handle those situations that can fend off such things, unlike in the other situation where such behavior is impossible because of lack of data at least some of the time. Some of the means can still be applied to the second type of list, but they don't make sense there because that just adds crap to jump through. The ultimate point here is that it should be _in the user's control_, not the ML admin's control. Certainly, the ML admin might want to say "No, I won't remove your accidentally posted sensitive information," and the ML admin has no liability to do so. But with any of the safeguards above in place, a ML admin could say that with confidence that the ML users have to deliberately act to post in the first place. Say the timeout method, List-Hold-For, would likely be most useful with a short value (say, 180 seconds by default), because most users realize that they screwed up _immediately_ after pressing the Send button. And guess what? That functionality then lets them cancel their post---putting control of a user's owned words/data in the hands of the user, and lightening the load of the ML administrator. Again, for lists that replies never go through automatically, that's simply not possible. So if we're going to talk about mitigating leakage issues here? The first type of list with the appropriate safeguards in place that the user can control with simple MUA-side headers and potentially additional UI enhancements on the MUA itself is the _clear_ winner. Somehow, though, I think that this conversation isn't about such things; I think it's about less concrete things altogether. > > This facilitates group discussion. It's not Orwellian, it's common > > sense > > The Orwellian behaviour is that ?reply to author? has been perverted > to mean something *totally* different. I don't get the impression that we're talking about users here, at all. I get the impression that we're going "Look! See? Bad! We know this to be true! What on earth are you thinking?", instead. I'm speaking in practical terms, from someone who uses software (and indeed, writes software, administers software, etc., so I'm not a non-technical end user). Using words like "perverted" makes it sound like, "I'm right, you're wrong, now go away." The standard is ambiguous. I'm sorry if you don't like that, but that _is_ the way it is. On top of the ambiguity there, I think that there is an assumption that whatever user interface that you're using that says "Reply to Author" is some sort of common thing among all MUA UIs, and it's not (probably _because_ the standards are ambiguous, though it could also be because the wording chosen most popularly is slightly more abstract anyway, even if the authors of the MUA don't see that Reply-To can apply to a mail from a ML server just as much as it can from a human directly). Again, I'm _not_ saying that ML software should override the reply-to header if it's already present in the message (though they do tend to do that anyway, and there's nothing we're going to change here on that). Fact is, they _do_, and that can be turned into something that can be used to prevent the very sorts of user mistakes being talked about here. Why it hasn't been before is beyond me. > For ?facilitate group discussion?, we have the ?reply to list? > operation ? implemented in most modern mainstream MUAs, and plenty of > pressure on the few recalcitrant vendors to get it right. > > > * During the course of the thread, it becomes clear that some sensitive > > information must be sent (to address your use case from your Web page > > from earlier in this thread). That's totally not a problem: The person > > asking for the sensitive information simply adds a reply-to header to > > their outbound message. > > This picture is so contrived I can't think of any situation where it's > actually played out as you portray it. Rather, the *person who wants > to send the private information* is the first one to know that's what > is needed ? so they hit ?reply to author? to send a reply to the > author of the message they're looking at. I forced nothing. The picture was posited earlier in the thread. I suggested a means of dealing with it, that's all. Read further into it if you want, but I don't warrant anything you read beyond the text... > Under your proposal, their intent is betrayed ? deliberately, by the > mailing list software. Even though the mailing list software is *also* > making available the standard RFC 2369 information facilitating group > discussion. You are forgetting that RFC 2369 can _only_ apply if the mail goes through the ML server in the _first_ place. Forgive me, y'all, for thinking I could talk from a user's point of view. I suppose I should know better. --- Mike * The answers being, "I don't know," "It means reply to the mailing list," and "It means reply to the person who sent it to the mailing list," or variants thereof. Because people are generally special, you may get more than 3 answers that are "creative". -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ The FSF merely is returning freedom to software, it did not invent it. But, what of history? Someday the FSF will go, a new proprietary era will come, and someone else will invent freedom in software for the third time. From turnbull at sk.tsukuba.ac.jp Wed Oct 14 12:04:05 2009 From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Wed, 14 Oct 2009 19:04:05 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255498516.13356.69.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> Message-ID: <87ws2yfg16.fsf@uwakimon.sk.tsukuba.ac.jp> Sorry, I didn't have time in my reply earlier to look up the citation in RFC 5322 (and (nearly?) identical language in RFC 2822). Here it is, along with an apology. Michael B. Trausch writes: > On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote: > > Michael B. Trausch writes: > > > > [This was me, stephen, but the attribution was dropped:] > > The attribution was _not_ dropped, Sorry, I must have missed it. I assure you I went looking for it in the yanked text. Apparently I had already cut it, somehow. My bad, explanation is not an excuse, only to help assure you it was not an intentional attack. > > Except that it is *not* an ultimate solution, because the function of > > the Reply-To field is lost in important cases. A new Reply-To field > > that third parties are prohibited from munging would have to be > > defined. Why do that when we already have one? > > Citation, please? I already quoted the part of RFC 2822 that shows that > semantically speaking your assertion is incorrect. >From RFC 5322 (http://www.rfc-editor.org/rfc/rfc5322.txt), sec. 3.6.2: The originator fields indicate the mailbox(es) of the source of the message. 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 "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. [...] The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply. In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also section 3.6.3 for more information on forming the destination addresses for a reply. The language in RFC 2822, section 3.6.2 is identical, or very close to it. Your interpretation of "originator" as "other end of the last hop" is specious. It's reasonable for users like you to delegate the use of Reply-To to the mailing list, but the mailing list is *not* the author in the case of discussion lists, and such delegation *must* be explicit, not assumed by the mailing list manager. > If there is an RFC that supersedes the definitions of RFC 2822, I'd > like to see it. At present, I am not aware of one. This information is generally available in the document rfc-index.txt, at the same base URL. For RFC 2822 it reads: 2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format: TXT=110695 bytes) (Obsoletes RFC0822) (Obsoleted by RFC5322) (Updated by RFC5335, RFC5336) (Status: PROPOSED STANDARD) Regards, Steve From barry at python.org Wed Oct 14 12:32:03 2009 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Oct 2009 06:32:03 -0400 Subject: [Mailman-Developers] Support for multiple domains in mailman3 In-Reply-To: References: Message-ID: On Oct 13, 2009, at 11:51 PM, John Goodell wrote: > Hello - I hope this is an appropriate place to post this question - > will > mailman 3 support multiple domain installations on one server? That > is, > currently a single mailman installation on a box can be setup to > distribute > to 1 domain name at a time - will we be able to run multiple domains > on a > single installation (on 1 server)? Yes. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From ben+bazaar at benfinney.id.au Wed Oct 14 08:30:26 2009 From: ben+bazaar at benfinney.id.au (Ben Finney) Date: Wed, 14 Oct 2009 17:30:26 +1100 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255498516.13356.69.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> Message-ID: <20091014063026.GK14800@benfinney.id.au> On 14-Oct-2009, Michael B. Trausch wrote: > On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote: > > Reply-To still is truly broken. The author wants personal replies > > to go to her, but now they go to the list. The recipient must > > *specifically avoid reply-to-author* in order to reply to the > > author. This is so Orwellian. > > Permit me to rephrase so that you understand what I said: > > There are two major uses of email [for actual discussion]: email > from one person or to one person or a group of people, and email > from one person to a mailing list (presumably with people on it). I can't parse the above into two; I assume there's a mistake, and that you meant ?email from one person to one or more people, and email from one person to a mailing list?. If you meant something else, I'm not seeing it. > However, the primary use-case for a mailing list is _group_ > _discussion_. Yes. This majority use, though, should not make it more difficult to use ?reply to author?. As has no doubt already been pointed out in this discussion, the failure modes are wildly unbalanced: * ?Whoops, I sent a message intended for the whole list instead as a reply to the author. Oh well, I'll re-send the reply to the list.? Annoying for the two people involved, but no permanent harm done. * ?Whoops, I sent a message intended only for the author instead as a reply to the whole list.? Completely the opposite of what ?reply to author? is supposed to do, and unrecoverable. > * I send an email to the mailing list to start a thread of > discussion. I send no reply-to header on the message, so the list > processing software appends one redirecting replies to the group. It directs the ?reply to author? replies to the group, despite the intent of the respondent. A recipe for disaster, as has been demonstrated countless times over the years. > This facilitates group discussion. It's not Orwellian, it's common > sense The Orwellian behaviour is that ?reply to author? has been perverted to mean something *totally* different. For ?facilitate group discussion?, we have the ?reply to list? operation ? implemented in most modern mainstream MUAs, and plenty of pressure on the few recalcitrant vendors to get it right. > * During the course of the thread, it becomes clear that some sensitive > information must be sent (to address your use case from your Web page > from earlier in this thread). That's totally not a problem: The person > asking for the sensitive information simply adds a reply-to header to > their outbound message. This picture is so contrived I can't think of any situation where it's actually played out as you portray it. Rather, the *person who wants to send the private information* is the first one to know that's what is needed ? so they hit ?reply to author? to send a reply to the author of the message they're looking at. Under your proposal, their intent is betrayed ? deliberately, by the mailing list software. Even though the mailing list software is *also* making available the standard RFC 2369 information facilitating group discussion. -- \ ?The greatest tragedy in mankind's entire history may be the | `\ hijacking of morality by religion.? ?Arthur C. Clarke, 1991 | _o__) | Ben Finney -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From barry at python.org Wed Oct 14 13:59:35 2009 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Oct 2009 07:59:35 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255475702.16706.33.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> Message-ID: On Oct 13, 2009, at 7:15 PM, Michael B. Trausch wrote: > I would say that if ML software _always_ overrides reply-to, even when > the author explicitly provided one, then that is broken. Aside from the other problems that have been pointed out, selectively overriding Reply-to makes the mailing list behavior almost impossible to predict. Whatever the legitimate pros and cons for always munging or never munging, at least it's predictable without the user having to hunt around in the Reply-To or being ultra-careful with their Send button, neither of which will happen for Real Users in the real world. > Even better, this eliminates the problem of: > > I post message A without reply-to: > > To: ml at example.org > From: mbt at zest.trausch.us > > Someone responds with message B and hits reply-all, also without > reply-to: > > To: mbt at zest.trausch.us > Cc: ml at example.org > From: user at example.org > > And then I don't get a message with a List-Post header _at all_. That > is one failing that your algorithm cannot fix, unless the ML sends its > second copy (and most MLs are configured not to do so, because users > find it inconvenient). Mailman leaves it up to the user to suppress the list copy if they are explicitly named on a recipient header. The downside of course is that the mailing list cannot suppress the off-list copy because it never sees it, so the only possibility is to suppress the copy with all the helpful mailing list bling. Of course, you can always use an MUA such as Gmail that "helpfully" suppresses messages with duplicate Message-IDs. I put that in quote because it's a FAQ that Gmail users never even see the list-copy of their own postings, and they often don't know if their message made it to the list. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From barry at python.org Wed Oct 14 14:34:15 2009 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Oct 2009 08:34:15 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255498516.13356.69.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> Message-ID: <6D60F495-62C4-435A-A118-DB0C8A46F985@python.org> On Oct 14, 2009, at 1:35 AM, Michael B. Trausch wrote: > There are two major uses of email, discounting automatically generated > messages, corporate crap and spam: email from one person or to one > person or a group of people, and email from one person to a mailing > list > (presumably with people on it). You need to at the coarsest break down the latter into sub- categories. Mailing lists can be discussion lists like this one, or "announce" (one-way) lists. Often, those latter lists want to funnel further discussion to a second mailing list. I don't see how selective Reply-To munging can support this use case. > However, the primary use-case for a mailing list is _group_ > _discussion_. Or at least, so I thought. Call me silly, but if it's > not meant to be group discussion as the primary role, maybe mailing > lists should stop using server software and become ad-hoc, old boys' > club style, personally shared and replicated distribution lists, > nothing > more. Being that is the case, and that is what users of mailing lists > _expect_, it is reasonable to assume that the way reply-to is handled > would be thus: Hyperbole aside, I don't believe this corresponds to what users expect. People need to know intuitively and consistently what their MUA buttons are going to do and will not hunt around in composition fields to try to figure that out. Mail.app for example has a Reply button and a Reply All button. I think the most intuitive interpretation of those is that the former replies to the author and the latter replies to all recipients (one of which happens to be the mailing list). Breaking that contract will piss people off and cause potentially serious damage, and doing so unpredictably will make matters worse. > * I send an email to the mailing list to start a thread of discussion. > I send no reply-to header on the message, so the list processing > software appends one redirecting replies to the group. This > facilitates > group discussion. It's not Orwellian, it's common sense---if, of > course, we make the assumption that mailing lists are for, you know, > group discussion and not private communication. It also breaks your MUA. > If I want to > communicate privately with someone, I won't be sending the mail to a > mailing list; if I need to communicate with someone who is on a ML > privately, and I don't have their address, that's what ML archives are > for (or, sending a mail to the ML to ping them, or searching my own > archives, if the public archives have that information stripped). Have you never wanted to reply privately to the author of a mailing message? I do all the time, and even though I trust my MUA and most mailing lists to be configured properly, I'm extremely anal about checking my headers (and sometimes after the fact, even checking my Sent folder ;). But I confidently state that this is aberrant behavior :) Most normal people will just trust their buttons and hit send. The damage this can cause is irreversible. > * During the course of the thread, it becomes clear that some > sensitive > information must be sent (to address your use case from your Web page > from earlier in this thread). That's totally not a problem: The > person > asking for the sensitive information simply adds a reply-to header to > their outbound message. The problem with this analysis is that it's not the original sender that gets to decide whether responses will contain sensitive information or not, it's the person sending the reply. > Citation, please? I already quoted the part of RFC 2822 that shows > that > semantically speaking your assertion is incorrect. If there is an RFC > that supersedes the definitions of RFC 2822, I'd like to see it. At > present, I am not aware of one. (Further, if there is additional > clarification that I've missed in my readings of RFC 2822, I'd like a > pointer to that, as well; I've already read it once today, maybe I'll > review it again later for things I missed in today's reading.) Here's what RFC 5322 $3.6.2 says: "The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply." There's no way that I can read that to suggest that the mailing list has any right to touch that field. This language says to me that Reply-To is firmly under the purview of the message's original author. > In my (admittedly, limited in terms of global and topical coverage) > personal experience, _most_ mailing lists are poorly configured on the > extreme of users not being able to specify a reply-to at all, because > the reply-to is stripped and subsequently replaced by the mailing list > software. Clearly, this is _bad_. Is it wrong? Not according to RFC > 2822, because the mailing list processor is the logical origin of a > message and thus it is clear to send the header---or not---as it sees > fit. I completely disagree. The MLM is not the "logical origin" of a message. > However, what sparked this thread was a practical concern > regarding a very common usage pattern, not a concern that everything > be > 100% idealistic and precisely fit some standard as interpreted by > random > person X. > > In other words, what we're talking about is left---according to the > ambiguous text in RFC 2822---as an implementation detail of mailing > list > processing software. Again, I disagree with this interpretation. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From barry at python.org Wed Oct 14 14:41:35 2009 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Oct 2009 08:41:35 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255508359.13356.170.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> Message-ID: <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> On Oct 14, 2009, at 4:19 AM, Michael B. Trausch wrote: > * MLs that require "reply all" instead, and instead of sending _one_ > message in threading context, send N number of messages where N is > however many people are listed in various headers. This is not a bug in mailing list software, it's a bug in the MUAs. Despite, as Stephen says, *decades* of complaints such as this, very few MUAs support the mailing list RFCs that have exists for at least a dozen years. Fix the MUAs first please. It's actually easy too. An MUA need only recognize List-Post and add a Reply to List button which would strip all the recipients and put the List-Post value in the To header. Problem solved. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From mark at msapiro.net Wed Oct 14 15:28:48 2009 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 14 Oct 2009 06:28:48 -0700 Subject: [Mailman-Developers] Support for multiple domains in mailman3 In-Reply-To: Message-ID: John Goodell wrote: >Hello - I hope this is an appropriate place to post this question - will >mailman 3 support multiple domain installations on one server? That is, >currently a single mailman installation on a box can be setup to distribute >to 1 domain name at a time - will we be able to run multiple domains on a >single installation (on 1 server)? Short answer, Yes. I'm not sure if you fully understand the Mailman 2.1 situation. A standard Mailman 2.1 instance supports multiple domains. The only restriction is that the same list name cannot exist in more than one domain. I.e. list names must be unique within a single Mailman instance. Some installations live quite happily with that restriction; others can't live with it at all and resort to multiple instances or patches. That restriction will be removed in Mailman 3. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Wed Oct 14 15:46:22 2009 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 14 Oct 2009 06:46:22 -0700 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255498516.13356.69.camel@zest.trausch.us> Message-ID: Michael B. Trausch wrote: > >Whether the emails are in a personal, >hobbyist, collegiate, educational, or professional context, the patterns >are largely the same. In both events, 95+% of the time, there is no >reply-to header attached by the authors MUA. Where do you get this statistic. I have no hard data, but I think it's doubtful. I see lots of mail generated with a Reply-To: containing the same address as the From: because the MUA's account wizard offers a reply-to field and the clueless user fills it in and all their mail is sent with a Reply-To: header. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mbt at zest.trausch.us Wed Oct 14 17:07:26 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Wed, 14 Oct 2009 11:07:26 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> Message-ID: <1255532846.9846.37.camel@zest.trausch.us> On Wed, 2009-10-14 at 08:41 -0400, Barry Warsaw wrote: > On Oct 14, 2009, at 4:19 AM, Michael B. Trausch wrote: > > > * MLs that require "reply all" instead, and instead of sending _one_ > > message in threading context, send N number of messages where N is > > however many people are listed in various headers. > > This is not a bug in mailing list software, it's a bug in the MUAs. > Despite, as Stephen says, *decades* of complaints such as this, very > few MUAs support the mailing list RFCs that have exists for at least a > dozen years. Fix the MUAs first please. As I mentioned in the post you replied to, this is impossible because the List-* headers won't be received at all in many normal operating circumstances. > It's actually easy too. An MUA need only recognize List-Post and add > a Reply to List button which would strip all the recipients and put > the List-Post value in the To header. Problem solved. And therein lies the rub. There are several ways to make the system work more deterministically overall (the list style that seems to be on the side opposite me here is _rarely_ deterministic, though it often kind of works). There are means by which accidental leakage can be avoided on lists that use the Reply-To header as I have already suggested, while not breaking what a non-technical end-user perceives to be expected behavior. I'm talking about user experience as it pertains to mailing lists and everything that there is to them. I cannot consistently reply without making something incorrect, nor can I consistently filter mailing list posts, because when posts arrive without a header to filter on (as is the case when I recieve someone's reply directly, and not from the mailing list) the filter breaks. Such breakage should be the exception, not the rule. Furthermore, such breakage cannot be fixed in a system where there isn't a single component to be fixed. Suggesting that this can be done MUA-side fails to address several issues that I raised in the post that you replied to that are programmatically impossible to solve consistently. I was unaware of RFC 5322's clarifications. That does change what I understand to be current standard a bit, but it does not change what I think is proper behavior in terms of how users interact with mailing lists. While both approaches can have inconsistencies about them, there are less of them in a system that uses reply-to with a sane default and does things like I discussed in the parent of your reply, and if any of the mechanisms were adopted that would virtually kill the "Oh, I posted stuff I shouldn't have" problem. I can think of many situations where it'd also be beneficial---say, in a flamefest, where someone sends off a message that they wished they could take back (impossible normally), or accidentally press Send by accident before finishing message composition (such as I did earlier in this thread), or in those few minutes just after someone hits Send and goes "Oh, I _really_ oughtn't to have done that." It is technically possible to solve these problems. What I don't understand is why there seems to be a large active disinterest in doing so. The mechanisms I mentioned earlier would all solve those problems for all but a very small subset of users---it'd fix the mailing list "user interface" for more users than the current methods do. Again, I think that _what is_ is being ignored for what is perceived to be _what ought to be_. I'm more interested in the practical concerns at play. Though, it seems that doesn't matter. That said, if mailing list software _did_ choose to modify/remove/replace/append to the reply-to header (mere creation of the header is _not_ munging) it's entirely possible that the ML software could be configured to handle such things gracefully. If the mailing list posts always go through the ML server, it _is_ possible to fix nearly every imaginable use-case, but for that to work, there would have to be some level of interest. IMHO, it's more important to Just Work regardless of what sort of MUA the user has than it is to be pedantic and play the blame game. If there is a technical solution that can be reliably implemented in an MUA-independent fashion that doesn't depend on any of the things I mentioned in this post's grandparent, I'd be interested in going after it. However, programmatically speaking, I don't see it being possible without saying, "MUAs, these are the standards that you must adhere to," in a separate standards document, describing exactly what sort of behavior is expected to make things transparent and just work, and also sending duplicate messages such that MUA software can recognize the duplicate and show them as a single message. I think that trying to fix it in the currently apparently accepted architecture, though, is terribly much more complex than it needs to be. What I am proposing is that depending on the MUA to be anything more than a program to send and receive messages is fundamentally flawed, and it doesn't fit in with the UNIX philosophy of program design. The job of managing the mailing list should be on the mailing list management software, no part of it should depend on the MUA. The MUA _should_ be able to provide help in doing so, but everything that the MUA is capable of doing automagically for its users should also be able to be done without depending on the MUA for extra help, in such a way that even very ancient MUA software that still exists out there (albeit in very rare usage) can provide the functionality, using nothing but messages to manage the flow of things. Maybe what I need to do to really show what I'm talking about is to create an implementation that does what I am talking about so that it can be looked at and discussed? --- Mike -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ ?The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.? ?Michelangelo From jmhayes at speakeasy.net Wed Oct 14 17:33:47 2009 From: jmhayes at speakeasy.net (Jordan Hayes) Date: Wed, 14 Oct 2009 08:33:47 -0700 Subject: [Mailman-Developers] Reply-To munging considered *carefully* References: <1255119636.9074.22.camel@zest.trausch.us><87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp><1255407098.12130.18.camel@zest.trausch.us><87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp><1255475702.16706.33.camel@zest.trausch.us><878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp><1255498516.13356.69.camel@zest.trausch.us> <6D60F495-62C4-435A-A118-DB0C8A46F985@python.org> Message-ID: This thread is a perfect example; "Reply-All" in my MUA puts all these people on the destination list, even though I'm pretty sure they are all on the list itself. Enjoy your duplicates! And if one of you *isn't* on the list, then you should join. Anyway, Barry asked: >> Have you never wanted to reply privately to the author of a mailing >> message? Of course. But it's not the common case; the common case is: continue the discussion, on-list. So you're wanting to do soemthing other than the default, so you should *have* to do something differently in order to accomplish it. Mailing lists are different from other kinds of email; otherwise why have lists at all? /jordan From barry at python.org Wed Oct 14 18:31:12 2009 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Oct 2009 12:31:12 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255532846.9846.37.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> <1255532846.9846.37.camel@zest.trausch.us> Message-ID: <29DE88C7-C292-4367-9476-D041BD3ED04C@python.org> Since this thread has devolved into the same unwinnable emacs-vs-vim argument about Reply-To munging, I'm going to disengage. Mailman's official policy won't change. It considers Reply-To munging to be a bad thing in the general case, and will discourage its use. It will still supply the tools to allow list owners to do it, but it may make such options more obscure. Support for Reply-To munging will not be removed if only so we can tell list owners to stfu, or to provide them cover to tell their users to stfu. :) Mailman also recognizes that there are a few limited legitimate use cases for a mailing list to indicate where follow up postings should go, and that there is currently no other way to support these use cases than Reply-To munging. Any attempt to impose additional semantics or responsibilities on Reply-To will only make matters worse. I support Stephen's efforts to rally consensus and eventual standards around an unambiguous less- contentious list-domain header for these use cases. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From turnbull at sk.tsukuba.ac.jp Wed Oct 14 19:05:56 2009 From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Thu, 15 Oct 2009 02:05:56 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> Message-ID: <87my3tgb2j.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > It's actually easy too. An MUA need only recognize List-Post and add > a Reply to List button which would strip all the recipients and put > the List-Post value in the To header. Problem solved. Wrong problem. The users Michael is representing want a one-button MUA. Now, nobody has come close to the one-button MUA yet (vc.el is pretty close, but unfortunately it's not an MUA), but the fact is that a *very* large proportion (not to be identified with the value "95%+", lest we rock Mark's coffin) of users get along perfectly well with only one reply button *as long as all their lists munge Reply-To*. See also Russ Nelson' pithy blog: http://russnelson.com/rt.html. My first response to that fact is "fuck 'em if they can't take a joke, 'cause the joke is their MUA".[1] However, as my mother always told me, you catch more bears with honey than with axle grease (or something like that), and thus the draft RFC. Footnotes: [1] From mbt at zest.trausch.us Wed Oct 14 20:20:27 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Wed, 14 Oct 2009 14:20:27 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <87my3tgb2j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> <87my3tgb2j.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1255544427.9846.49.camel@zest.trausch.us> On Thu, 2009-10-15 at 02:05 +0900, Stephen J. Turnbull wrote: > Barry Warsaw writes: > > > It's actually easy too. An MUA need only recognize List-Post and add > > a Reply to List button which would strip all the recipients and put > > the List-Post value in the To header. Problem solved. > > Wrong problem. The users Michael is representing want a one-button MUA. Not at all. I am _not_ only advocating a single position here. I'm advocating that there is, can be, should be, and must be a universally applicable solution found here. That said, I think the MUA is simply the wrong place for it; current models aim to control the user in one way or another, or lack flexibility in exchange for convenience or vice versa. It doesn't have to be that way; it's not 1970, folks. Perhaps what is really required to make _everyone_ happy is a system that is _designed_ to make everyone happy. Let's face it: Most software in the realm of mailing lists is aimed for at least a marginally technical audience. Why not aim more broadly and create something that _can_ make everyone happy, without saying "your MUA is broken," and for that matter is 100% functional in a manner that is 100% MUA-agnostic. Only a user can judge if his/her MUA is broken; you cannot do it for me, and I cannot do it for you. If you want to use "mail" at the command line, I'd say that's a poor choice of MUA, but you know what? I'm not you, and so why should I care? It is not my place to impose upon you requirements for proper MUA, Newsreader, Web browser, or any other technology's behavior. Here is an idea that is a _starting point_, that maybe would be useful to pursue. I doubt anyone here would be interested, but I plan to pursue it anyway: http://mike.trausch.us/blog/2009/10/14/on-mailing-list-management-software-part-1/ Short link: http://is.gd/4jzy9 --- Mike -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ ?The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.? ?Michelangelo From mbt at zest.trausch.us Wed Oct 14 20:23:26 2009 From: mbt at zest.trausch.us (Michael B. Trausch) Date: Wed, 14 Oct 2009 14:23:26 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <6D60F495-62C4-435A-A118-DB0C8A46F985@python.org> Message-ID: <1255544606.9846.52.camel@zest.trausch.us> On Wed, 2009-10-14 at 08:33 -0700, Jordan Hayes wrote: > Anyway, Barry asked: > > >> Have you never wanted to reply privately to the author of a mailing > >> message? > > Of course. But it's not the common case; the common case is: > continue > the discussion, on-list. So you're wanting to do soemthing other > than > the default, so you should *have* to do something differently in > order > to accomplish it. > > Mailing lists are different from other kinds of email; otherwise why > have lists at all? Exactly. I've also needed to reply privately. I find it _far_ easier to remove addresses from the To: bar than it is to look them up and add them. Of course, that's just me: I'm not ?ber-1337 or anything like that, so I don't have an SQLite database or 30 in my head. See my reply from a few moments ago for (the start of!) an idea that might make sense in today's technological environment and aims to please both ends of the spectrum, including people close to the middle such as myself. --- Mike -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ ?The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.? ?Michelangelo From stephen at xemacs.org Wed Oct 14 20:42:53 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 15 Oct 2009 03:42:53 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255508359.13356.170.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> Message-ID: <87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp> Michael B. Trausch writes: > Now, _this_ is where the situation is _bad_. It's _awful_. If every > single ML worked in precisely the same way, there would be _zero_ > issues. Well, yes. That's why there are RFCs, so that software and its users can interoperate over the Internet. You either really don't understand the relevant RFCs (the hypothesis I now favor) or you are advocating nonconformance. Both inadvertant and deliberate nonconformance are bad for the Internet, even if short-circuiting the RFC process seems like it would be real convenient to you and hundreds of millions of others right now. > Forgive me, y'all, for thinking I could talk from a user's point of > view. I suppose I should know better. We're *all* talking from the user's point of view. We all eat our own dogfood here, you know. The reason your proposals are getting treated so roughly is that they involve using *other* people's resources to serve *your* purpose, and non-conformance to an Internet standard that has been 40 years in the making. But the problem that you want to fix is that despite having all the information needed to DTRT, *your* MUA doesn't DWYM! The solution to that is obvious: fix your MUA, either by fixing it or by switching to a better one. Until you explain to us why that obvious solution is infeasible, you're going to get very little sympathy when you ask us (ie, wearing our list manager hats) to conform to a non-standard that you propose, in violation of an ancient and beloved real standard. From stephen at xemacs.org Wed Oct 14 21:49:53 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 15 Oct 2009 04:49:53 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255544427.9846.49.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <6E80B6A3-35F8-4213-A1E6-5B96A01F994A@python.org> <87my3tgb2j.fsf@uwakimon.sk.tsukuba.ac.jp> <1255544427.9846.49.camel@zest.trausch.us> Message-ID: <87k4yxg3ha.fsf@uwakimon.sk.tsukuba.ac.jp> Michael B. Trausch writes: > That said, I think the MUA is simply the wrong place for it; > current models aim to control the user in one way or another, or > lack flexibility in exchange for convenience or vice versa. It > doesn't have to be that way; it's not 1970, folks. How you can get from the last three lines to the first one is beyond me. My apologies to the rest of the audience for persisting this far. Exit Steve, stage left. From turnbull at sk.tsukuba.ac.jp Fri Oct 16 04:43:16 2009 From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Fri, 16 Oct 2009 11:43:16 +0900 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <1255621047.4358.20.camel@zest.trausch.us> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp> <1255621047.4358.20.camel@zest.trausch.us> Message-ID: <871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp> Michael B. Trausch writes: > My main, central, and driving point is a desire to create a system that > is both idiot friendly and expert friendly, and my desire is to have all > known common (end-user) and uncommon (technical user) use cases be > handled in a manner that is consistent and portable. That's what we want, too, Brother Michael. The difference between you and us is that we believe in the RFC process, we believe in decentralization, and we believe that if we design a better way to do it in that context, software developers will adopt it and users will get the benefits merely by upgrading their favorite software (or changing, if another implementation becomes more attractive in the process). From barry at python.org Fri Oct 16 05:43:35 2009 From: barry at python.org (Barry Warsaw) Date: Thu, 15 Oct 2009 23:43:35 -0400 Subject: [Mailman-Developers] Reply-To munging considered *carefully* In-Reply-To: <871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1255119636.9074.22.camel@zest.trausch.us> <87tyy7lm4x.fsf@uwakimon.sk.tsukuba.ac.jp> <1255407098.12130.18.camel@zest.trausch.us> <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp> <1255621047.4358.20.camel@zest.trausch.us> <871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org> On Oct 15, 2009, at 10:43 PM, Stephen J. Turnbull wrote: >> My main, central, and driving point is a desire to create a system >> that >> is both idiot friendly and expert friendly, and my desire is to >> have all >> known common (end-user) and uncommon (technical user) use cases be >> handled in a manner that is consistent and portable. > > That's what we want, too, Brother Michael. The difference between you > and us is that we believe in the RFC process, we believe in > decentralization, and we believe that if we design a better way to do > it in that context, software developers will adopt it and users will > get the benefits merely by upgrading their favorite software (or > changing, if another implementation becomes more attractive in the > process). Can I get an "Amen"?! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From bob at nleaudio.com Fri Oct 16 05:51:47 2009 From: bob at nleaudio.com (Bob Puff) Date: Thu, 15 Oct 2009 23:51:47 -0400 Subject: [Mailman-Developers] Request for MM project hire Message-ID: <20091016034500.M680@nleaudio.com> Hi Guys, I was just speaking to a client today who has a few thousand-ish one-way list on one of my boxes. They have a separate FileMaker database that holds each person's name, physical address, phone, and email address. They have been manually double-entering data into both this database, and their Mailman list. They don't want to do that anymore. They called me today asking for a quote on somehow merging this, so there is only one database. I'm thinking perhaps some sort of extension to the current MM database to hold their additional fields would do it. If a person unsubscribes, it nukes them. If an email bounces, then it does as the bounce processing dictates, and nukes them if it should. A web interface (with proper authentication) should be available for them to manually enter data, and I would guess they would also want at least a one-time import from their FileMaker database into this to populate all the current entries with the additional fields. I'm not skilled enough in Python to do this myself... I'm wondering if anyone here is willing to take on the project. And in a somewhat-related question to this list, is MM 3.0 going to be the solution? Will it handle additional fields like this? Please reply privately if you wish to take on the project, with a price guesstimate. Bob From lists at psycho.i21k.de Fri Oct 16 06:17:57 2009 From: lists at psycho.i21k.de (Bernd Siggy Brentrup) Date: Fri, 16 Oct 2009 06:17:57 +0200 Subject: [Mailman-Developers] AMEN [was: Reply-To munging considered *carefully*] In-Reply-To: <1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org> References: <87pr8rhj2y.fsf@uwakimon.sk.tsukuba.ac.jp> <1255475702.16706.33.camel@zest.trausch.us> <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp> <1255498516.13356.69.camel@zest.trausch.us> <20091014063026.GK14800@benfinney.id.au> <1255508359.13356.170.camel@zest.trausch.us> <87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp> <1255621047.4358.20.camel@zest.trausch.us> <871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp> <1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org> Message-ID: <20091016041757.GA3237@puntila.winnegan.fake> On Thu, Oct 15, 2009 at 23:43 -0400, Barry Warsaw wrote: > Can I get an "Amen"?! Here it is :) Siggy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From wallacegerheim at gmail.com Thu Oct 29 12:13:32 2009 From: wallacegerheim at gmail.com (Gerheim) Date: Thu, 29 Oct 2009 09:13:32 -0200 Subject: [Mailman-Developers] Network is unreachable Message-ID: Hi, I've terminated to configure my server but when I create a list, the welcome message stops on queue. Analysing /var/log/mailman/smtp-failure I get: Oct 29 09:04:29 2009 (18551) delivery to test at xxx.xxx.xxx failed with code -1: (101, 'Network is unreachable') Could anyone help? Thanks Wallace Gerheim