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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
