[Mailman-Users] non-subscribers getting through--email address in "Real Name"
Stephen J. Turnbull
turnbull.stephen.fw at u.tsukuba.ac.jp
Wed Jul 25 06:03:29 EDT 2018
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
(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:
>>>>> 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
(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.
More information about the Mailman-Users