As of last Christmas, I am on 100% validation of Mail From:. Previously unseen domains that cannot produce SPF PASS go to system quarantine.
After review, acceptable messages get a local policy to provide alternate positive identification, usually of the form:. server domain name, fcDNS on server name, and Mail From domain. This solves the identification problem without whitelisting, so messages still have to pass content filtering. Unacceptable messages get blacklisted. Either way, the authentication problem does not need to be revisited for that domain. In a few cases, I have solved SPF problems by trusting any domain on a particular server platform. It adds risk, but reduces the level of effort wasted on lower risks, so I can concentrate on higher risks. I am not yet on 100% From validationm I don't know if I will ever get there, but my framework could support it in theory. Right now, a lot of smaller ESP traffic gets through without From verification, as long as it passes content filtering. I am filtering for my own organization, so I have to make the CEO happy while keeping the organization free of devastating malware. I had to build a custom Sender Authentication process because I could not buy it anywhere But this group is not interested in the general authentication problem. It is only interested in the tiny subset of mail with DMARC p=reject. That scope definition has been a big disappointment for me. Doug On Tue, Apr 4, 2023, 12:31 AM Jesse Thompson <z...@fastmail.com> wrote: > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
