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
- *author* = author is authorized to send from her apparent domain
- *list-verified* = list is authorized to send from its apparent domain *and* it authenticated the author
- *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@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.<wink> See http://turnbull.sk.tsukuba.ac.jp/Blog/Software/ReplyToMungingConsideredEmCar... for something I wrote for a different venue just today.
- 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:
- 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
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.....