On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote: > 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
I have been thinking lately of an intent-based model that seems similar to what you describe. What I am referring to as intents are what you are referring to as operating policies. The customer of an ESP (the author) wants to do X, Y, Z. That is their intent, expressed in good faith. Presumably. The ESP offers guidance on deliverability practices to help the customer be successful with their objectives. A common agreement between the customer and the ESP can be established. The ESP wants to enable the customer to do what they stated, but cannot guarantee that the customer might stray from their intent or be lying. What actually happens in practice can be validated. Stray from intent can be measured. In theory. Ultimately, the ISP decides whether to trust the mail. Currently, the customer needs to warm up their reputation because the ISP has no idea who the customer is and what their intent is. They are protecting themselves from the risk that the customer might suddenly stray from their predictable flow of harmless mail. If the customer does something the ISP does not like, the ISP might decide to block the ESP's shared IP space, affecting other customers of the ESP (causing those other customers to seek solace on the ever-depleting IPv4 dedicated IP address space) So, I was thinking of a mechanism where the customer (indexed by their authenticated identifier) could publish their intent, the ESP can publish what it thinks the customer's intent is, and maybe also publish its measurement about the customer's adherence to/deviance from their stated intent (which I acknowledge is a potential privacy issue). The ISP can do their own measurements of the inbound mail against the intents that have been published, and make a determination based on that. Ideally, this transparent model would reduce the need for the ISP to punish the ESP for assuming [incorrectly] the good faith (or adherence to best practices) of a customer, while also giving the ISP information it needs to react quickly when bad things happen. Customers may rely less on warming up their relationship with the ISPs as long as they ensure they do not stray from their published intent. Maybe it needs a feedback mechanism so the ISP can say something to the customer and their ESP like: You said you were going to do X, but X_a actually happened. The customer can consult with their ESP to fix their deliverability problems, or the customer can be asked to cease their business relationship with the ESP. The primary blocker with this model is the ESP's requirement to preserve the privacy of its customers. The secondary blocker is that not all intents may be easily measurable (e.g. confirmed opt-in) I know I am using the word "customer" here when I should be using "author". That's because I have been thinking about this from the perspective of an ESP, which enables the added benefits of a 3-party relationship (perhaps like a certificate authority's role with HTTPS). Could an intent, or stream-info, model work between 2 parties? Jesse > > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
