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

[Grant Taylor]

On 07/25/2018 04:03 AM, Stephen J. Turnbull wrote:
> Let's be careful to distinguish between "DMARC" and the "p=reject" and 
> "p=quarantine" policies.

Fair point.

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

Agreed.

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

I personally disagree.

I'll concede "SHOULD" in the typical sense that RFCs use it.  Thus my 
opinion is contrary to the recommendation.

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

Odd.

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

Yes, I did.

I'm sure that people had the best of intentions.  I'm not trying to 
impugn anybody.  Mistakes happen.  Undesirable results happen.  A recent 
example that comes to mind is the renegotiation issue with a MitM on TLS 
1.2.

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

It's my understanding that one of the functions of DKIM was to allow 
messages to be forwarded, (with the body) unmodified, and still 
providing a high degree of certainty that (the signed portion of) the 
message was the same as it was submitted into SMTP.  (Assuming that the 
submission server did the DKIM signing and that it's the same domain as 
the purported sending email address.

I feel the need to pause for a moment and reflect on that assumption. 
As I type this, I realize that it's relatively easy to break that 
assumption without breaking DKIM.  …  Thus, DKIM itself can't "…ensure 
that the *purported author domain* of an email can be authenticated…"

I'm leaving that here in case it helps others who might have been 
confused by that fact like I was.

> *The whole purpose of DMARC From alignment is to authenticate the author 
> domain in the context of her message!*

Okay.

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

Agreed.

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

At a minimum, yes.  You could also state that I'm proposing regenerating 
a completely new and independent message, quite a bit more than munging 
a message.

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

Only if the From: header has the original sender's email address.  [1] 
If the From: header reflects the mailing list, there is no DMARC 
conflict with the original sender's domain.

[1]  I think it may be possible to move the email address into the human 
friendly portion of the address and replace the actual email address 
with that of the mailing list.  I.e.:

      From: Grant Taylor <gtaylor at tnetconsulting.net>

Becomes:

      From:  "Grant Taylor <gtaylor at tnetconsulting.net>" 
<mailman-users at python.org>

It is my understanding that DMARC implementations are supposed to ignore 
the human friendly portion of the email address.  However I do not feel 
comfortable trusting that.  As such, I would likely alter the text that 
looks like an address in the human friendly portion to be something like 
this:

      From:  "Grant Taylor - gtaylor (at) tnetconsulting (dot) net" 
<mailman-users at python.org>

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

I don't know if I'd call that "broken" per say.  But I don't object to 
the point.

> Some styles would look a little better, some worse.  All, gag me.

To each his / her own opinion.

> This is imposing work on a lot of MUA authors, and it will be ongoing 
> as mailing lists keep changing their munging styles.

I don't see how this imposes additional work on MUA authors.

Or are you suggesting that MUA authors alter what the MUA does in a 
perpetual game of whack-a-formatting-mole?

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

That would only apply to email from me through a mailing list.

But I take your point.

> (This is a controversial point: a lot of security pundits believe that 
> most users will click on anything anyway.)

Sadly true.

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

Okay.

IMHO this speaks to how mailing lists are configured, specifically what 
they modify.

> (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!)

I disagree in so far as I believe that the MTA hosting the mailing list 
can perform SPF validation as the message comes into the mailing list.

Granted, SPF can't do anything to help subscriber's receiving MTAs 
validate the purported author's domain.  If anything it's likely to fail 
SPF if the SMTP envelope is unmodified.

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

Fair.

I think "if the mailing list is accepted as trustworthy by recipients" 
is going to be the Achilles heal of ARC.  At the very least we're going 
to end up with a priming problem.

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

Okay.

You're free to have your own opinion.

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

Interesting points that I'll mull over.

Thank you for the constructive conversation Steve.



-- 
Grant. . . .
unix || die