On Mon, Apr 3, 2023, at 8:30 PM, Douglas Foster wrote: > I described my algorithm because I am surprised that some of these > sub-optimal filtering problems exist.
I would have thought the DKIM domain to be a better authenticated identifier than MailFrom domain; messages from ESPs are typically double-signed with DKIM (giving the evaluator the choice/multiple signals), but can have only one MailFrom and that can be either the ESP's domain or the customer's (depending on their ability to delegate via DNS). Let's not cast judgement. It's an issue of lack of mutual understanding. > 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. A better analogy is if the bouncers were not employed by the same organization as the bartenders. What kind of contract between the bouncer firms and the bar owner is required? > 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'm not seeing how you identify an ESP from not an ESP > I only use DKIM to assess the From address. Assuming you are talking about DMARC logic here. If the message isn't DKIM aligned or SPF aligned, yet came from an ESP, what do you conclude with your assessment? > 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. ++ Jesse > > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
