I described my algorithm because I am surprised that some of these sub-optimal filtering problems exist.
As a corollary: In an American bar, the bouncer checks I.Ds. on the way in, so that the bartender does not have to check IDs on every drink. Similarly, I assume that a major ESP has compelling business practices to ensure that the From address on an outbound message matches the account used to domain used to sign up for service. Therefore, I don't have to recheck identity because the identity has been (or should have been) checked by the ESP. I have opted to delegate authentication trust to the ESP, until they betray me. We can't put that approach in an IETF standard, but we could put it into a Best Practices document. But I am surprised that we would need to do so. I expect anyone that is trying to filter traffic correctly to come to a similar conclusion, because the volume of unsigned mail from ESPs is enormous. You cannot justify blocking it all and you cannot investigate every one. Yes, for most ESP traffic, the ESP is in the MailFrom domain and passes SPF, usually on against server with the same domain that passes fcDNS. So ESP identification is not a concern for me. I only use DKIM to assess the >From address. Your "intent" parameters and my "operating practices" seem to be pursuing the same goal: establishing trust by defining metrics that can be verified over time. Doug On Mon, Apr 3, 2023 at 7:00 PM Jesse Thompson <z...@fastmail.com> wrote: > 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
