On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote:
> My approach to ESP traffic is simple. I assume that the ESP has authorized
> the account indicated by the From address, so I don't worry about Sender
> Authentication as long as the message passes SPF based on the ESP domain.
> DMARC is about identity verification, and I am counting on the ESP to ensure
> that identity verification.
What you're describing looks like a black box (e.g. should I assume that you
don't use DKIM, only SPF, to identify the ESP?).
So, you might resolve the identity to the message's author (despite there being
no authentication mechanism to do so), or you might not. And every other
receiver has their own logic (if any).
> ESPs develop a reputation with me based on their ability to vet their clients
> appropriately.
Do we need a set of best practices for ESPs to appropriately vet clients before
emitting email that otherwise carries no authenticated identifier aligned to
the rfc5322.From?
Are we conflating "predicting whether their intentions are good and will not
stray" with "verifying they are otherwise capable of sending authenticated mail
from the address"? I'm not sure it's fair to insist that trust is a
prerequisite just for communicating authenticated identifiers. The ESP (or
intermediary) mostly needs to know if sending unaligned email is going to cause
a problem; not that they are trying to absolve itself from other problems.
> (Right now my biggest spam problem comes from Gmail.com accounts that are
> verifiably identified but being misused. Identity verification is not the
> solution to all spam problems, it is just the one that is easiest to address
> with standards.)
The abuse might be coming via Gmail's authenticated identifiers, or it might be
coming from an ESP's authenticated identifiers. It's still the same spammer (or
compromised account) in both cases. Why would we not want a standard that can
attribute the abuse to the gmail.com identity? Just because the domain is used
by normal users?
> On the specifics of your proposal, I am unclear what types of "intent" you
> would put into a client profile.
Something along the lines of: This is the rfc5322.from, verified by X, expected
volume/patterns, expected nature/category(ies) of content, recipients are
confirmed opt-in, supported feedback mechanisms, has one-click-unsubscribe,
etc. Basically all of the things that are discussed when giving deliverability
guidance to someone building a new email program, but more tangible and useful
for all parties.
But it might depend on the use case. Such as indirect mail, which is what
you're getting at with Stream-Info, I think.
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
