Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2015 23:15:17 -0700

On Wed, Apr 29, 2015 at 5:04 AM, Stephen J. Turnbull <[email-masked]>
wrote:

> J. Gomez suggests:
>  > > >     That would force DMARC-compliant Mediators to reject (or accept
>  > > >     but not resend) incoming email from p=reject domains,
>  > > >     irrespective of whether such mail passes or not the initial
>  > > >     incoming DMARC checks.
>
> Something about having mediators (ie, non-MTAs) implement this check
> was bothering me.  I realized that the nagging thought was the
> *Mediator* doesn't have to do it.
>
> Variation A:
>
> The *outgoing MTA* can do this check; it has the same information (the
> "From" field, the DKIM signature, and the DNS) that the mediator does.
> This outgoing check is just a variation on the spamfighting theme of
> "if pretty much anybody can send from your system, you have to check
> outgoing mail as well as incoming mail."
> [...]
>

Outgoing from the Author, or outgoing from the Mediator?

Either way, it seems to me that this is something a fully compliant
participant might do, but that broken or hostile actors won't bother doing.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 10 May 2015 02:31:43 +0900

> > The *outgoing MTA* can do this check [for a modified and relayed
 > > message that fails From alignment]; it has the same information
 > > (the "From" field, the DKIM signature, and the DNS) that the
 > > mediator does.
 > 

Outgoing from the Mediator.

 > participant might do, but that broken or hostile actors won't

Ah, but mailing lists are *already* doing it, at least GNU Mailman
implements an optional check for DMARC policy at the Author Domain,
and munges if and only it's reject or quarantine.  It's a popular
feature.  I'm just saying this could be implemented in the MTA as
well, and it might go on the list of things you need to implement to
get a Good Housekeeping Seal of Approval.

---

From: Michael Jack Assels <[email-masked]>
Date: Sat, 09 May 2015 13:52:37 -0400

On Sun, 10 May 2015 02:31:43 +0900, 

> get a Good Housekeeping Seal of Approval.

Isn't the ideal objective of DMARC to be so reliable that *everybody*
uses it with p=reject.  At that point, 5322.From addresses will all
be munged.  Why not skip the complexity and start munging them all now?

I'm not particularly keen on this as a solution to DMARC's MLM problem,
but there's no doubt that it would settle the issue.

MJA

---

From: "John Levine" <[email-masked]>
Date: 9 May 2015 20:43:34 -0000

>uses it with p=reject.

No.  Most domains aren't subject to significant phishing attacks, so
for them it's useful for incoming mail from Paypal et al, but not for
outgoing mail.

> At that point, 5322.From addresses will all

Ewwww.

R's,
John

---

From: Michael Jack Assels <[email-masked]>
Date: Sat, 09 May 2015 19:26:31 -0400

On 09 May 2015 20:43:34 -0000, 

> for them it's useful for incoming mail from Paypal et al, but not for

I take it that a *significant* phishing attack is one where the
5322.From domain is involved with money, and the hook is a URL at a
free web hosting site where the phisherpholk will harvest credentials so
they can get some of that money?

If that's the case, then perhaps you're right.  Our little university
domain gets plenty of annoying but insignificant phishing attacks,
with the perps looking for credentials for ordinary student/faculty
accounts that they can use to launch other, sometimes significant,
phishing attacks (or just send a lot of spam).

However, if the whole point of p=reject is to protect a relatively small
number of sensitive domains like Paypal, iTunes, et al., then maybe it
would be helpful simply to say so in a forthcoming standards track RFC,
perhaps with words like

   A domain SHOULD NOT publish a p=reject policy if it will emit mail
   intended to be mediated with modifications by another domain unless
   the mediating domain is exempted from the policy by [fill in the
   eventually approved mechanism(s)].

That would at least nudge errant ESPs away from their misguided ways,
and the rest of us can honor p=reject without losing any sleep over it.

> > be munged.  Why not skip the complexity and start munging them all now?

FWIW, I did write that I wasn't keen on that approach.  :-)

MJA

---

From: "John Levine" <[email-masked]>
Date: 10 May 2015 00:31:43 -0000

>they can get some of that money?

No, it's one where the volume is high enough to be annoying.
Sometimes it's looking for money, sometimes it's looking to steal
account credentials or other stuff.  I expect your users get phished a
fair amount to steal accounts.  But I also expect a lot of those
phishes would be unaffected by DMARC.

>   eventually approved mechanism(s)].

Right, that horse left the barn a year and a half ago.  At this point
we're doing damage control, viz. my double signing proposal which
would make it somewhat easier for mailing lists et al to do what they
do without the problem of current approaches that all lose useful
features and/or require retraining users.

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 11 May 2015 00:11:22 +0900

>    eventually approved mechanism(s)].

That won't work; you don't want to exempt mediating domains, you want
to exempt specific mail flows destined for those domains.

Anyway, I seem to recall that discouraging wording was in drafts
around a year ago (but not at the level of SHOULD NOT, since searching
for SHOULD NOT doesn't find it).  But even a SHOULD NOT wouldn't have
any effect, as representatives of the "errant domains" take the postion
that "we didn't *want* to, but we were *forced* to publish p=reject".

 > That would at least nudge errant ESPs away from their misguided

Yahoo! claims that malicious mail flows of over 1 million messages per
minute went away like magic when they published p=reject.  An RFC
nudge won't be noticed compared to the business consequences of that.

 > and the rest of us can honor p=reject without losing any

But that's not a problem any more.  Go ahead, honor p=reject.  Mailing
lists have been forced to adopt mitigation measures because the errant
domains themselves honor p=reject, and I don't know what 3rd-party
originators have done -- mostly closed up shop, I suppose.