Laura's faith in developers exceeds mine. Having just completed a second survey of commercial products, I found very few that could handle all of the most needed exception conditions.
For mailing lists, the exception rule is easy: If SMTP address = List address (or list domain) and SPF PASS, then ignore DMARC enforcement. If a product offers the necessary exception capability, and the system admin is responsive to user needs, the problem is solved with a support ticket. If the system admin does not wish to meet the needs of his users, or cannot be convinced to trust the list, there is nothing that we can do. System admins will always block messages that they do not trust. But if the problem is lack of product features, we can address that problem. Ergo, we cannot induce AOL to stop enforcing P=reject for inbound messages from mailing lists. But we can document what is necessary for trusting a list message when trust is granted. Doug On Mon, Aug 8, 2022, 3:10 AM Laura Atkins <la...@wordtothewise.com> wrote: > > > On 8 Aug 2022, at 05:10, Murray S. Kucherawy <superu...@gmail.com> wrote: > > On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Evaluators need to use much more sophistication, when applying DMARC, >> than simply applying the formula and doing whatever the policy suggests. >> > > I think that's common practice. The people on this list who are still > M3AAWG regulars can tell me if I'm wrong, but my impression is that it is > common industry practice to factor the output of DMARC, just as DKIM and > SPF, into to whatever local secret sauce an operator chooses to employ when > making handling decisions. DMARC is rarely dispositive on its own. There > are plenty of other practices that usually go into a final handling > decision; RFC 6647 comes to mind as one example, RFC 5782 as another. > > > DMARC is never dispositive on its own. Neither is SPF. Neither is DKIM. We > have on record ISPs saying they look alignment regardless of a DMARC record. > > The various forms of authentication form an identity to hang reputation > off. No matter the alignment there is still an identity between the 3 > different domains. > > This SPF + This DKIM + This 5322.from domain = This Mailstream > > This Mailstream has This Reputation. > > This Reputation means we’ll deliver the mail [Inbox | Spam folder] for > users we don’t have specific data for. > > For users we do have specific data (or filters) related to This Mailstream > we will deliver the mail depending on their specific preferences. > > DMARC is not a filtering mechanism, and it does not say anything about > whether a mail is spam or not. It merely says: This company authenticates > its mail in a very specific way and requests the receiver do something if > the message they see is not authenticated in that very specific way. It > does not say This mail is good mail or this mail should go to the inbox or > this mail is wanted mail. All it says is if you see mail that is not > authenticated in this way, these are the actions we’d like you to take for > that mail. > > Developers need to provide exception mechanisms which permit that >> complexity to be implemented as local policy. This means we need language >> to deprecate implementation designs that assume Fail=Malicious. >> > > We can't require such mechanisms as they are outside of the scope of the > protocol, but we could say it's common to do so. For that matter, Section > 1 of RFC 6647 already says this: > > Absent a perfect abuse-detection mechanism that incurs no cost, the > current requirement is for an array of techniques to be used by each > filtering system. They range in cost, effectiveness, and types of > abuse techniques they target. > > Given the number of actual DMARC implementers, and by that I mean the > folks who are writing the libraries and the underlying code to manage DMARC > authentication, I don’t think we really need to go into it. This isn’t > being implemented by every organization hosting their own mail, it’s being > implemented by a few thousand people across dozens of independent projects. > > laura > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > 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
