[Mailman-Developers] dkim and email list software - potential solution

Daniel Black daniel at cacert.org
Fri Oct 9 05:22:18 CEST 2009


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.

> <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:
1. global dkim-friendly= true to disable list modifications parameters
2. 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).

> 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 at python.org> 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: <http://mail.python.org/pipermail/mailman-developers/attachments/20091009/9748dd82/attachment.pgp>


More information about the Mailman-Developers mailing list