On Thu, Jan 6, 2022 at 8:12 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> Protocols are created to solve a problem, and solution design should > include both normal operation and failure management. That’s why > electrical panels use circuit breakers instead of simple on-off switches. > > In this current case, we are defining an access control system for email, > so we have easy parallels with an access control system for doors. The > core protocol defines how the badge is formatted, how the reader > interrogates the badge, and how it interprets the response. But the > solution is much more. The solution needs to include a way to cope with > employees who forgot their badges, badges that don’t work, guests who do > not have a badge, solenoids that don’t open doors when the badge reads > successfully, the emergency exit path if there is a fire, and probably > other things. > > Mailing list messages can be considered equivalent to an employee who > arrives at work without his badge. Assume that an organization wants to > trust mailing list messages from IETF.ORG. How is this accomplished? > My analysis says that there are ways to do this right and ways to do this > wrong. I have seen an abundance of wrong implementations. Defining how > to do it right is an example of failure management. I do not believe that > it is irrelevant to the protocol; rather it should be an integral part of > it. > I think if you extend that logic to its conclusion, the core protocol for email should contain DKIM, SPF, DMARC, maybe MIME, maybe greylisting, DNSXLs, and a host of other things. It would be massive. I would wager that the manual for the badge readers at your place of work or mine probably doesn't talk about what policy you should have for employees who forget badges, handling of guests, emergency exits, or most of the other things you listed. How could it possibly know the right answers to such questions? I'm sure at least for reasons of liability, they are tightly scoped, and such things are left to the purview of the customer who has full context of how the reader is going to be used. Since the email ecosystem evolves, parts are added over time and other parts become obsolete, best practices evolve with new usage, etc., it's more agile for us to be crisp in separating protocol from advice. We commonly publish protocol specifications in Standards Track documents and then include advice of the sort you're advocating in Informational documents. This also allows us to evolve the advice text separately from the protocol documents when doing so is warranted. It also means the protocol can advance toward publication while we might still be haggling about the advice part. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
