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

[Stephen J. Turnbull]

Daniel,

 > > [hacking the from] is 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.

Er, do you think we write open source purely out of charity?  We are
all operators and users ourselves.  (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?

 > Even less forthcoming is the reasons the lack of acceptability that
 > could guide standards or implementations.

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

2.  Authorship information is lost, or at best obscured.  You point
    out that most MUAs don't present List-* headers.  Well, they don't
    present Sender or In-Reply-To either (except for Outlook).  You're
    either in the From header, or the users don't know about it.

3.  Sophisticated users filter on From.  This breaks the filters
    bigtime once, and makes them more fragile forever after.

4.  It's ugly.

 > 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

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

2.  From: rewriting.  Thank you, but it is already a feature of most
    list software because it is required for common applications
    (announce lists, anonymous lists, and probably others I don't
    remember offhand).  Adapting that to this purpose is nearly
    trivial.

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

Nonsense.

1.  ADSP is vulnerable, too.  Besides the Safemail! hack described
    below, there are any number of obscure RFC 822 features (and yes,
    they're still present in RFC 5322) available:

    From: cs at yourbank.com (Customer Service)                       .phisher.net

2.  Anybody who is sufficiently unsophisticated or distracted to get
    caught by any of the email phishing scams I've seen is not going
    to be checking ADSP on authors, anyway.  So this is *not* about
    users, it's about ISPs/email providers.  *They* see *all* the
    headers, and they either filter (based on reputation) or provide
    notification of authentication results to users.

    Eg, Google and other providers tag mail "This mail probably did
    not come from the purported author.  Don't click on anything in
    it."  Mail which is only LDSP-authenticated can be tagged "This
    mail failed author authentication.  Do not provide personal
    information to its sender by replying to it or clicking on
    anything in it."

3.  List mail by its very nature (lists are traffic aggregators) is
    unreliable.  Obviously the amount of trust you put in LDSP-
    authenticated mail is *much* lower than that you put in ADSP-
    authenticated mail.  Still, in the current environment I'll take
    any bonuses I can get, and as long as I behave, I suspect the big
    ISPs would be willing to allow me to build up some cred.

4.  ADSP is just as meaningless as LDSP, unless it comes from a
    reputable party.  As has been pointed out already in this thread,
    DKIM and ADSP are helpful only because they allow ISPs to keep a
    reputation database based on reliable identification of sender
    domains.  You don't rely on something just because it's signed.
    LDSP is the same (but attenuated, #3 still applies).

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

 > > Perhaps if it is known that the DKIM signature of the author's
 > > host is going to remain valid,

 > this would be idea.

Sure, but it's rarely the case.  See "best practice and unsubscribe",
above.

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

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

Nonsense.  It depends on the reputation of the list and the sending
domain, just like From, which is just as easy to spoof, and reasonably
easy to confuse the gullible.

 > please explain why this is harmful.

Ugly (makes every MUA look as broken as Outlook).  The From header is
an *Originator header*; it is a violation of the RFCs to change it.

 > It seems that anonymous discussion lists have worked so slightly
 > manipulated From addresses would also work.

Apples and asteroids, for heaven's sake.  *You* want them to work, so
you call completely different contexts similar.

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

Reply-To is also an originator field, munging it violates the RFCs.
It's not obvious what the right thing to do if the Reply-To field
exists.  For example, I often set it to a list.

And, per your suggestion, let's just take that return-path variant and
see what we can do with it.

    From: "JP Morgan Customer Service via SafeMail!"
          <joe-victim+service=morgan.com at safemail.akamai.163.com>

Uh-oh.  I *know* I've seen *that* domain somewhere before.  Now, right
now that looks suspicious.  But once people get used to jumbles like

    From: "Daniel Black via mailman-developers list"
          <mailman-developers-from+daniel=cacert.org at python.org>

they will stop trying to parse addresses at all (assuming the poor
phish ever did in the first place).