It is not about fixing the text, it is about fixing the design. Authentication has only 2 states:
- Authenticated, therefore judged free of impersonation risk - Unauthenticated, therefore possibly an impersonation and possibly a malicious impersonation. The Unauthenticated result can occur for many reasons other than malicious impersonation, and many unauthenticated messages are actually acceptable. Therefore, an unauthenticated result is always an ambiguous result. Ambiguity always requires collection of additional information. Authentication state is an attribute of a mail stream. When information gathering resolves an ambiguity, that new information must be codified into local policy, so that the ambiguity is eliminated for all future messages with the same characteristics. For unwanted mailstreams, the local policy is implemented as a block rule. For wanted mailstreams, the local policy is implemented as an alternate authentication rule. An alternate authentication rule is always possible once the responsible identifier is determined. Some mail flows cause authentication to be lost in transit, while other mail flows cause authentication to be gained in transit. Consequently, the true Authentication state cannot always be determined using the final state of the message. Authentication analysis will be a process of continuous improvement to ensure that indirect mail flows are handled optimally. - - - Since the group has spent years working from inferior design assumptions, can we fix the problem with a Best Practices document? Doug Foster
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
