For purposes of the following discussion, assume that messages from known-bad senders and messages with unacceptable content have already been blocked. The question at hand is how to handle Sender Authentication failure when a message has no other objectionable characteristics.
There are three possible states for a message that is unauthenticated but otherwise unobjectionable: 1) Authorized by domain owner but not verifiable due to configuration errors or omissions by the sender. 2) Authorized (implicitly or explicitly) by a single domain member, or sent for their benefit. Inherently not verifiable with domain-level validation. Mailing List messages are one example in this category. 3) Not authorized by anyone and therefore illegitimate. This framework applies to any unauthenticated message, including DMARC FAIL or NO POLICY, as well as SPF FAIL, SOFTFAIL, PERMERROR, NEUTRAL or NOPOLICY. Category 1 and 2 are (by assumption) legitimate messages, but without authentication they are indistinguishable from Category 3 illegitimate messages. A DMARC policy of p=reject says that there will be no Category 1 messages. Even when true, it does not resolve the ambiguity between Category 2 and Category 3. The only way to resolve ambiguity is with more information. One important aspect of this question is whether the user wants the message. I have two approaches for handling these unauthenticated messages. - Relaxed mode: Deliver the message to the user, then perform an in-depth review after the fact. - Strict mode: Deliver the message to system quarantine, then review before releasing to the user. System quarantine is used because: - I understand how to view and interpret the message headers. - The quarantine review tool can present the message in a safe-mode view - My user-mode quarantine review tools do not provide the user with enough information to make an intelligent decision. This approach works well for me, but it does not work for Big Tech because it requires too much labor. Instead, the work needs to be distributed by sending "Strict Mode" messages to user quarantine. This requires a creation of user quarantine wizards that help the user make an intelligent decision and automate the creation of disposition rules to affect future messages. With any review, the goal is to characterize a message stream of which the current message is an example. In some cases, it may be unclear how to convert individually approved messages into a message stream definition. Big Tech is likely to be pretty good at this, but their inference engines could be assisted by information provided from the message source, using a URI header like this Stream-Info: http://dmarc.listpracties.ietf.org. Below are two examples of what information could be provided in a stream info declaration. A formal specification would be needed but is not provided. For the IETF Mailing List stream, those characteristics are: - The message stream type is: Mailing List - Identifier information: - SMTP MailFrom is always dmarc-boun...@ietf.org and produces SPF PASS - Messages are signed by ietf.org - HELO domain is ietf.org and can be forward-confirmed - Reverse DNS domain is ietf.org and can be forward-confirmed - ARC Sets are not added to forwarded messages. - Operating Policies: - Every post is verified to the subscriber with DMARC or challenge-response verification - From header is rewritten for messages with DMARC p=reject - Incoming messages are converted to text mode, and a footer is added, so prior signatures are invalidated For a simple user-to-user forward, the characteristics could be: - The message stream type is: User Forward - Identifier information: - Previous TO domain was example.com - SMTP MailFrom is SRS encoded version of the original sender - ARC Sets are added to forwarded messages - Operating policies: - Messages are scanned for malware on a best-effort basis. - Content is not modified, so prior signatures are preserved, but not all messages will have prior signatures Doug Foster
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
