gtaylor at tnetconsulting.net
Wed Jul 25 14:55:15 EDT 2018
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.
> 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
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
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
> 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".
> 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.
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.
> 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
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
More information about the Mailman-Users