Grant Taylor via Mailman-Users writes:
> On 07/25/2018 03:53 AM, Stephen J. Turnbull wrote:
> > That's not how "on behalf of" worked in practice. What happened in April
> > 2014, was that a home business owner (HBO) would send a pile of completed
> > order notices to intuit.com, and intuit.com would send an invoice to each
> > customer on behalf of h...@yahoo.com, from h...@yahoo.com.
>
> Will you please clarify what the SMTP envelope from and the From: header
> were in the example(s) that you're talking about?
>
> I'm going to assume (for the sake of discussion or until corrected) that
> both the SMTP envelope from and the From: header were
> h...@yahoo.com.
I don't know about the envelope of such messages, which is irrelevant
to DMARC. I suppose it typically was "h...@yahoo.com". The fact that
DMARC From alignment fails for Yahoo! addresses indicates that the
typical From address was "h...@yahoo.com".
> > Tens of thousands of invoices worth millions of dollars bounced off of
> > personal accounts and tiny business owner accounts at Yahoo! and other
> > receivers who take p=reject as a command.
>
> I assume "bounced off of" means that the messages were rejected by
> receiving MTAs that honored Yahoo's (et al) p=reject DMARC configuration.
Yes.
> I'll argue that DMARC is designed to 1) detect such spoofed email
> forgeries
They were neither spoofed nor forged. The authority to use that
address was delegated in conformance with RFC 5322, just as an
executive delegates signature authority to a secretary.
> and 2) enable Yahoo (et al) to publish what they would like to
> be done with such spoofed email forgeries.
In both (1) and (2) remove the word "such", and you are correct.
> Granted, all the rejected / bounced invoices are contrary to the
> behavior that many individuals wanted.
And there were substantial costs. Many SMEs had income delayed for
weeks.
> I assume that this detection and rejection of any email claiming to be
> from Yahoo that didn't actually originate from Yahoo is exactly what
> Yahoo wanted to happen.
No. It's exactly what they expected to happen, but they acknowledge
that such mail is legitimate. Their position was to stand on the EULA
and say "tough luck, sometimes things don't work out -- what did you
expect for free?"
> I feel like this is saying "We want something to detect the bad
> guys and block them, but still allow the good guys to do the exact
> same thing as the bad guys." That has never worked very well.
Your definition of "exact same thing" seems to be "whatever gets
caught by DMARC p=reject", which is circular for present purposes.
The original purpose of DMARC p=reject was to prevent spear-phishing
by spoofing existing relationships, typically financial, and getting
recipients to click links they shouldn't. These are "transactional"
mail flows, ie, business mail direct from vendor to client. It wasn't
intended to prevent all spam defined as *any* UCE, as a fair amount of
UCE originates from addresses owned by the sender.
So DMARC was not intended to prevent spam in general, at least not by
the time I joined the WG mailing list. Although some people were
still advocating that the death of mailing lists as we know them is a
small price to pay for universal p=reject, the majority, including
senior Yahoo! admins, denied that.
The Yahoo!/AOL problem, once again, was that leaking a billion address
books to spammers made spear-spamming feasible and profitable.
("Spear-spamming" is a word I just made up, meaning use of "From: Your
Friend" to get victims to pay attention to UCE that they would
otherwise ignore with extreme prejudice.) They were "forced" to use
p=reject in a situation it wasn't designed for.
> What would you want to see done, as Intuit's CISO, instead of what I
> propose?
Have clients' customers extend limited trust to intuit.com. I'm not
going to go into it because I haven't done and don't have time to do a
proper analysis, even a sketchy one. For what it's worth, my
intuition is that there is no particular "trust" benefit to having
clients delegate subdomains to Intuit rather than just having their
customers trust Intuit (of course Intuit needs to sign its mail), but
there are substantial costs in DNS management and increased attack
surface.
If you want to explain why you think there *is* a trust benefit, I'd
like to hear it. On my side it's just a feeling. :-) I'm quite
confident about the costs, though.
> I would certainly hope that the company that I'm outsourcing
> financial transactions to could secure the systems that process
> money.
As I understand Intuit's main business affected by p=reject in 2014,
financial transactions weren't outsourced to Intuit, only accounting
(including tax preparation) and invoicing.
> I think anything that spoofs or otherwise pretends to send as someone
> they are not is a form of abuse.
That's inconsistent with RFC 5322. Distinguishing the agent
responsible for the content from the agent who submits the message is
the whole purpose of the Sender field. I see no difference between a
human executive secretary and an automated on-behalf-of service in
this respect. But DMARC doesn't care what's in Sender -- or in the
SMTP envelope, for that matter. It only deals with From, specifically
with the author domain. And this is the right field for the purpose,
because it is the author that the spear-phishing victim trusts, not
the submitting agent.
I think your notion of "spoof" is too formal, it is inconsistent with
RFC 5322, and therefore not well-adapted to understanding the effects
of DMARC p=reject. That doesn't mean your belief that mailing lists
should adapt to DMARC, rather than DMARC adapting to a world with
Mediators (see RFC 5598) in it, is "wrong", just that it's hard to
have a conversation.
> I also believe this form of abuse is (at least partially) exactly
> what DMARC is designed to prevent.
DMARC is designed to prevent spear-phishing, not submission of
messages by agents other than the author. Yahoo! and AOL, and a few
other domains, also use it to prevent spear-spamming.
Steve
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
