[Mailman-Developers] dkim and email list software

[Stephen J. Turnbull]

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

1.  *author* = author is authorized to send from her apparent domain
2.  *list-verified* = list is authorized to send from its apparent
    domain *and* it authenticated the author
3.  *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 at 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/ReplyToMungingConsideredEmCarefullyEm
for something I wrote for a different venue just today.

 > > 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?

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:
 > 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

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.....