[Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Stephen J. Turnbull]

Grant Taylor via Mailman-Users writes:
 > On 07/24/2018 03:16 PM, John Levine wrote:
 > > Turning it on for aol.com, yahoo.com, and other domains with user 
 > > mailboxes,
 > 
 > So, are you stating that DMARC should NOT be used on domains that 
 > (predominantly) contain end user mailboxes?

Let's be careful to distinguish between "DMARC" and the "p=reject" and
"p=quarantine" policies.

(1) DMARC's reporting features *can* and *should* be used on all
    domains that send email, with very few exceptions.

(2) "p=reject" should never be used on domains that contain any
    non-transactional mailboxes (ie, mailboxes used as the From which
    might be reinjected into the mail system with changes).  This
    recommendation was actually in some early unofficial drafts or
    author discussions of RFC 7489, but doesn't appear to be in the
    Internet-Draft prepublication series, and it's definitely not in
    the published RFC.  (I believe that keeping such verbiage out of
    the RFC is why the RFC is informational rather than normative.)

 > "legitimate mail that DMARC cannot describe"  That sounds distinctly 
 > like a problem with the DMARC specification, /not/ with use there of.

Hey, did you really want to write that?  There's about a millennium of
mail-RFC-writing and/or large site admin experience on the DMARC-WG.

So, there's fundamental misunderstanding here somewhere.  DMARC
depends on DKIM and SPF.  Neither can ensure that the *purported
author domain* of an email can be authenticated when passed through a
mailing list.  *The whole purpose of DMARC From alignment is to
authenticate the author domain in the context of her message!*  This is
simply impossible, unless the signed portions of the message arrive at
the destination *unchanged*, or the list is an authorized mail source
of the author domain for SPF.  Much legitimate email *does* change them,
however, and few lists cater exclusively to subscribers of the same
administrative domain.  (Of course getting list host IPs authorized as
mail sources for all potential SPF-using posters would be a nightmare!)

You propose that mailing list should munge From (and in fact you've
proposed that it should do so independent of DMARC, IIRC).  AFAICS,
this has three nasty effects (at least).

(1) It ensures that validation of From alignment of the actual author
    will *fail*, because the From header *must* be signed in DMARC.
    (SPF is pretty useless in the context of mailing lists.)

(2) It breaks all the quoting mechanisms in every existing MUA, which
    now instead of, e.g.,

    >>>>> Grant Taylor writes:

    will insert

    >>>>> Grant Taylor <gtaylor at tnetconsulting.net> via Mailman-Users writes:

    Some styles would look a little better, some worse.  All, gag me.
    This is imposing work on a lot of MUA authors, and it will be
    ongoing as mailing lists keep changing their munging styles.

(3) Users may start to accept

    From: "Grant Taylor <gtaylor at tnetconsulting.net> via
          All-Passwords-Yours-Now-Ours ML" <vlad at kremlin.ru>

    (or whatever their MUA displays) as indicating authentic email
    from you, because a lot of authentic mail indeed looks like that
    in your scheme.  (This is a controversial point: a lot of security
    pundits believe that most users will click on anything anyway.)

 > I feel like DMARC requires a paradigm shift in how email is forwarded 
 > and handled by mailing lists.

Three points for your consideration here:

(1) There's a fundamental problem, though: the *only* paradigm shift
    compatible with DMARC's goal of authenticating the author's domain
    is to *pass the message through with all signed portions
    unchanged.*  (SPF doesn't have this problem: SPF can't authenticate
    author domains of mailing list posts *at all*, unless the list is
    hosted by the author's domain or its host's IP is listed as a valid
    mail source by the author's domain!)

(2) DMARC is a *private protocol*.  RFC 7489 is *Informational*, it
    has *no normative implications* for the rest of us.  We would be
    perfectly conformant to all normative RFCs if we decided that mail
    from sites that have a p=reject policy is undeliverable and
    dangerous, and rejected it.  We're not going to do that, nor even
    offer it as an option, but I'll leave that here for consideration.

(3) ARC, if the mailing list is accepted as trustworthy by recipients,
    requires *no* change to mailing list behavior (aside from
    participation in the ARC protocol, of course).  If not trusted,
    we're back in the world of (1) and (2).

 > I suspect "imposed on innocent bystanders" and "not their problem" can 
 > also be used to describe requiring reverse DNS, SPF, and DKIM.

No, it can't, not in the same way.

(1) All of the above can be implemented in the MTA without any change
    in end user or Mediator behavior.  These upgrades were frequently
    transparent to admins of virtual domains (except that their mail
    started working to sites it used to fail at).  Not so, DMARC.
    Most mailing lists munge Subject, or add footers, or both.  Either
    those modifications have to be abandoned, or the address in From
    must also be munged.  Most of us find those alternatives extremely
    distasteful.

(2) All of those requirements may result in denial of service to
    posters, but not to subscribers.  Turning on "p=reject" did DoS
    unrelated subscribers whose providers participate in DMARC.

Steve