Jesse observed that ESPs sometimes have difficulty getting a delegated DKIM scope, because it delegates authority an entire namespace:
With an assist from the DKIM group, we could specify that a DKIM signature without a "d=" term is valid. The "i=" term would have to be a full email address and the key lookup would be done by parsing the domain portion of the "i=" term. Then the DKIM signature becomes valid for DMARC only when the entire "i=" address matches the full RFC5322.From address. It would encounter several obstacles: - Evaluator participation: Senders have no information about whether their intended recipients will trust the signature - Domain owner participation: Would Gmail and AOL be willing to let individual account owner create DKIM keys of this type? - Scaling: What happens when the DKIM key path for a mailbox provider's domain is cluttered with millions of user-created entries? But there is probably a way to make it work. 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
