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.
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.
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.
Sophisticated users filter on From. This breaks the filters bigtime once, and makes them more fragile forever after.
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:
- global dkim-friendly= true to disable list modifications parameters
- From: rewriting
- 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:
- technology standardisation - (LDSP, DKIM Third-Party Authorization Label, Sender DSP)
- deployment practice standardisation - http://tools.ietf.org/html/draft- ietf-dkim-deployment-08#section-6.3
- deployment promotion - inclusion in, for example, mailman installation manual / site administrator documentation
- ensuring DKIM verification tools development supports this.
- 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