
Stephen,
Thanks you for your responses.
In that case it is very often a violation of ... RFC 5322). Surely you already know that!
On Thursday 08 October 2009 17:07:30 Stephen J. Turnbull wrote: 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.
- global dkim-friendly= true to disable list modifications parameters
- From: rewriting
</RANT>
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).
<RANT> 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:
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" <mailman-developers- from+daniel=cacert.org@python.org> and add a reply-to: daniel@cacert.org if the header field doesn't exist for MUA compatibility.
-- Daniel Black Infrastructure Administrator CAcert