[Mailman-Users] ARC

[Grant Taylor]

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 hbo at yahoo.com, from hbo at 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 hbo at yahoo.com.

> HBO, of course, doesn't have a vanity domain, just a Wordpress or 
> SquareSite (or even Facebook) home page.

~twitch~

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

I'll argue that DMARC is designed to 1) detect such spoofed email 
forgeries and 2) enable Yahoo (et al) to publish what they would like to 
be done with such spoofed email forgeries.

Granted, all the rejected / bounced invoices are contrary to the 
behavior that many individuals wanted.

But this also enabled DMARC enabled receiving MTAs to detect and reject 
other less white hat spoofed email forgeries.

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.

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.

> Note that if I were intuit.com's CISO, I would fight tooth and nail 
> against the system you suggest, because it implies that I have DKIM 
> private keys for all those subdomains owned by clients.

What would you want to see done, as Intuit's CISO, instead of what I 
propose?

My purpose of the sub-domain of the client's domain is to transition 
(some of) the trust of the client's domain to Intuit's sub-domain 
therein.  I.e. I trust ietf.org, therefor I'll also trust intuit.ietf.org.

It is possible for Intuit to use a completely separate domain, 
intuit-ietf.org.  But there is not the same implicit relationship 
between intuit-ietf.org as there is intuit.ietf.org.

The intuit.ietf.org sub-domain is a completely different DNS zone that 
has been delegated from ietf.org to Intuit for them to manage / 
administer / operate for the purpose of hosting requisite services for 
IETF to be a client of Intuit.

What would you rather see done?  Does it also convey trust the same way 
that intuit.ietf.org does?

> Every spammer in the world would be trying to hack the server that has 
> those keys.

Why does that need to be one server?  What if it's a separate VM per 
client?  (I'd personally like that and pay more for such separation as 
Intuit's client.)

Assume for a moment that they are separate VMs.  How does the security 
of Intuit running X number of VMs differ from X number of clients 
running a VM?

I would think that it would actually worsen security posture because I 
would assume that Intuit would have a better understanding because of, 
and more data from, the larger population of VMs to administer.

Who knows more about securing things:  The thousand different entities 
that run one (or few) instances of something, or the one (or few) 
entities that run many instances of said thing?

> I could probably keep them out, but Lordy, the liability involved!

I would certainly hope that the company that I'm outsourcing financial 
transactions to could secure the systems that process money.  I'd really 
hope that they could also secure systems that only process email.  With 
the security of the former systems exceeding the security need of the 
latter systems.  One stringent security policy protects both sets of 
systems.

> Less financially painful are the services that newspapers and tourist 
> destinations provided (note past tense, they're mostly dead now) where you 
> could sit at a terminal and send a "postcard" recommending an article or 
> with a picture of the attraction to family and friends "from" yourself, 
> including your email address, simply by typing name and address in. 
> Not a huge loss, I guess, but ....

I think that all of those systems were behaving badly.  I think that 
they SHOULD have been sending with something like this:

      From:  Uncle Sam (via My Picture Kiosk) <lax at mypicturekiosk.com>
      To:  Cousin Larry <larry at mysmallisp.net>
      Reply-To:  Uncle Sam <coolunclesam at gmail.com>

      Hi Cousin Larry,

      Check out this cool picture!!!

      --
      Uncle Sam sent you this picture from the LAX airport.

I think anything that spoofs or otherwise pretends to send as someone 
they are not is a form of abuse.

I also believe this form of abuse is (at least partially) exactly what 
DMARC is designed to prevent.

> I've never seen SRS in the wild, except in the headers of some of the 
> crazier denizens of IETF mailing lists.  YMMV, of course.

I know that there is little love for SRS.  But I see little reason not 
to use it.  Yes, I am practicing what I preach.  Both of my email 
servers are configured to support SRS.

> Simple .forwarding breaks SPF of the author domain, period, unless 
> entirely within one administrative domain, and that domain is 
> well-configured so that all the forwarding is internal, and the SPF 
> checks are all done at the boundary.

I would question how proper the SPF and / or forwarding configuration is 
to even allow it within an administrative domain.  Though I suppose an 
SPF record that allows any IP within the enterprise IP space to send 
would allow that.  Even that seems overly lax to me.

> I guess in the case where forwarding takes place entirely within an 
> administrative domain, DMARC From alignment could be broken without 
> breaking SPF itself because From alignment is validated on a different 
> host from SPF, but that sounds like a case of "evolution in action".

Ew....

> That's non-conforming to RFC 7489.  Section 4.2:

Sorry, I conflated PASS / FAIL with reporting again.

> I'm afraid I failed to make the concept explicit again.  Remember, 
> authenticating mail origin doesn't prevent anyone from sending malicious 
> mail, or even from having it delivered.

Agreed.

Just like HTTPS doesn't mean that the website isn't bad.

> So while I suggest that ARC processing results be taken seriously in the 
> presence of (List-* headers) for DMARC alignment purposes, delivery is 
> also conditional on (not malicious).

I mostly agree.

> If a site wants to be conservative and assume some degree of malice until 
> it's seen "enough" benign traffic, that's consistent with what I intended.

Fair enough.

> Also, sites like GMail and Yahoo! might very well be willing to specially 
> handle From addresses at sites known to have leaked a billion address 
> books.  Similarly, they could "throttle" on floods of ARC email via 
> purported mailing lists that have never been seen before.

That sounds more like big data type analytics to determine the quality 
of a message.  Once you start applying analytics to messages, you 
completely change the ball game.  (Bring your own ice skates.)

> I acknowledge that sites managed by single admins would likely be 
> unwilling, and perhaps even unable, to come up with such systems.

I suspect that there will (eventually) be services that smaller players 
can leverage / subscribe to that allow local hosting of this type of 
spam filtering.

I'd be interested in a service that was an appliance that I could 
configure Sendmail to use as a milter.  Much like ClamAV scanning on a 
box that sites beside the MX.  Substitute BigDataFilteringService in 
place of ClamAV.

> N.B. By "intended," I mean to admit that my wording in the previous post 
> strongly suggested that they would start with the assumption that mail 
> is benign until proven otherwise.  I can't fault you for taking my words 
> literally. :-)

Thank you for clarifying.

I try not to assume incorrectly, and prefer to ask.

Thank you for the conversation Steve.



-- 
Grant. . . .
unix || die