Thank you Jesse for your comments. You are focusing on the ESP problem, which I had not given much thought.
ESP messages My approach to ESP traffic is simple. I assume that the ESP has authorized the account indicated by the From address, so I don't worry about Sender Authentication as long as the message passes SPF based on the ESP domain. DMARC is about identity verification, and I am counting on the ESP to ensure that identity verification. ESPs develop a reputation with me based on their ability to vet their clients appropriately. ConstantContact seems to be mostly free of malicious content, so previously-unseen domains are delivered as long as they pass content filtering. SendGrid has not done so well. Previously-unseen domains are delivered to quarantine until I can vet them individually. One ESP has such a high rate of garbage that I have blocked them completely, but that is rare. Hopefully your organization is one that vets its clients pretty well. I tend to assume that the most sophisticated evaluators are doing something similar, but apparently not, or your organization would not be stressing over how to handle the DMARC-affected clients. (Right now my biggest spam problem comes from Gmail.com accounts that are verifiably identified but being misused. Identity verification is not the solution to all spam problems, it is just the one that is easiest to address with standards.) Mailbox provider accounts and ESP accounts are reminders how overwhelming it is to attempt a reputation system based on every sender. The set of all identifiers is nearly infinite. But I am trying nonetheless. On the specifics of your proposal, I am unclear what types of "intent" you would put into a client profile. Forwarded Messages I differ from most of the group because I believe the problem with forwarded messages needs to be handled between the forwarder and the evaluator, not the originator. The solution also needs to be based on message stream characteristics. It is inefficient to evaluate every message individually as if similar ones had never been seen before. My Stream-Info idea is most directly comparable to (or competitive with) ARC. ARC is a way for the forwarder to provide information that it hopes the evaluator will use to ignore sender authentication failures caused by changes in transit. The right to forward-with-changes is essentially a privilege escalation, and privilege escalation needs a well-delimited scope (which messages are included) and justification (why are we doing this) as well as trust (I believe you will not abuse your privilege.) The privilege also needs to be granted by the party most likely to reject the message, and that is of course the evaluator, not the originator. The stream and its identifier characteristics are intended to create a mutually-agreed scope. The "operating principles" section is part of the justification for the request: "You can trust me, because I am doing these good things" Those things cannot be verified on a single message, but they can be inferentially validated when all messages in the message stream are consistent with the asserted principles. I don't think ARC provides enough scope definition, does not provide enough justification, and it does not define a message stream. Finally, it lacks a feedback mechanism so it cannot solve the From-munging problem. The Stream-Info data could reasonably include a feedback address, which would also have a formal structure for automated processing. For forwarded traffic, the two feedback types that immediately come to mind are: - Trust granted: You do not need to Mung addresses for this message stream. - Cease and Desist: Our account user2@domain1 does not want messages to be forwarded from your account user1@domain1. Both types of messages would be sent only a few times, and intermittently, not on every message. Doug Foster On Sat, Apr 1, 2023 at 9:04 PM Jesse Thompson <z...@fastmail.com> wrote: > 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
