Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
On April 2, 2023 5:01:20 PM UTC, Alessandro Vesely wrote: >On Fri 31/Mar/2023 18:16:28 +0200 Scott Kitterman wrote: >> On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely wrote: >>> On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote: On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote: > Does that mean that instead of "non-transactional mail flows" we could say > "mail flows involving decades old software"? If you're going to put that label on MLMs, we need to add it to MTAs too. Oh and most of the protocols we're talking about. This is a pretty deep rabbit hole. >>> >>> Agreed. Yet, did you notice, for example, the steady decrease of >>> X-MIME-Autoconverted breakage cases? The hype on security sped up software >>> upgrading quite noticeably. >> >> Yes, but it didn't actively make the software less useful, so it's not >> really relevant to this case. > > >Eh? Some auto-conversion filters were implemented by rather elegant filters >able to decode and/or encode on the fly based on peer's capabilities. That >stuff became less useful, if that's what you mean... Less needed maybe, but in any case not really the same thing. That may have accelerated prioritization of technical resources to abate the issue, but in that case there's no negative impact to upgrading. Mailing list changes to ameliorate damage due to DMARC are in no way an improvement. Absent DMARC, they would not be needed at all. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Namespace delegation limits
On Sun, Apr 2, 2023, at 9:25 AM, Jim Fenton wrote: > On 2 Apr 2023, at 4:19, Douglas Foster wrote: > > > 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. > > Regardless of whether that’s a good idea, that would be an enormous change in > the way DKIM works and would not happen given the scale of existing > deployment. I was discussing implementing using an ATPS lookup, not changing DKIM > Besides, what’s the difference between this and just including the From > address in the DKIM signature? It's not about whether the address can be authenticated. It's about whether the delegated DKIM signer should be able to have signing authority of the entire address space when the domain owner has a least-privilege approach to security matters. > I think what you are looking for is a way to delegate a key that is valid for > only a specific address, rather than the whole domain. Or valid for multiple addresses, yes. I'm thinking: change ATPS to include the hashed local-part of the 5322.From when constructing the "._atps." DNS query. .._atps. The signer only needs a single key (for their own domain, no need for DKIM DNS delegation) and the domain owner only needs to publish a TXT record for each of the localparts within the rfc5322.From domain they choose to delegate to the signer's domain. Otherwise, as I mentioned, I don't see what ATPS brings to the table which isn't already possible with DKIM via CNAME record delegation. > Why not just create a subdomain for the ESP to use like marketing.example.com > and publish keys there? I think I said that. That is ideal. In the world of enterprise IT, starting a suggestion with "why not just..." is good way to learn how complex an organization really is (after the sarcastic griping). Sometimes organizations insist on using their organization domain for mixed-use purposes, or have been doing so for a long time and don't want to change, people pull rank and refuse to change, the person who can make the change is long gone, some legacy monolith needs to be upgraded first, or whatever happens inside a complex organization. The domain owners (email/dns administrators) aren't going to it find very helpful to point at the RFC where it says "MUST NOT do the thing that we and our peers have been doing and things seem ok anyway". The discussion has been circling around this idea that domain owners are doing a wrong/naive thing by publishing p=reject on their mixed-use domains. But they are doing it anyway. Don't real-world implementations carry weight? Why are they doing it? They are doing it because they think they value the perceived security benefit. People who value security value least-privileged delegation of authority. If such a mechanism existed, the domain owner might choose to use it to delegate the ability for random employees to use the few remaining non-rewriting mailing lists without having to sacrifice the perceived security benefits for their entire domain/user-base. Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Namespace delegation limits
It would not have to be an incompatible change, we could just change the way DMARC interprets signatures: If the "i=" term includes a local-part, then the signature is only valid for that one From address (regardless of the domain alignment policy). Otherwise, the signature is valid for any address local-part in any domain or subdomain that matches the DMARC alignment policy. Installations based on RFC 7489 will continue to interpret the signature broadly. This eliminates compatibility concerns, while weakening the effectiveness of creating a new control for domain owners. My impression is that fully qualified addresses are relatively rare on DKIM scopes used for email, so I really don't expect that a change in interpretation would have much effect on existing mail streams. But that is an assumption rather than a known fact. Perhaps we could work together to collect some data to assess whether the change would be trivial or significant. As to the subdomain technique, Jesse indicates that it is used sometimes, but transitioning can be difficult even when it is used. More importantly, it is not applicable to a small business that uses a mailbox provider account, yet wants to use ConstantContact for some marketing newsletters. That small business does not have the option of obtaining a Gmail subdomain. In short, we have two groups of unhappy users, and we need to acknowledge them both: mailing lists and ESPs. Doug Foster On Sun, Apr 2, 2023 at 10:25 AM Jim Fenton wrote: > On 2 Apr 2023, at 4:19, Douglas Foster wrote: > > > 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. > > Regardless of whether that’s a good idea, that would be an enormous change > in the way DKIM works and would not happen given the scale of existing > deployment. Besides, what’s the difference between this and just including > the From address in the DKIM signature? > > I think what you are looking for is a way to delegate a key that is valid > for only a specific address, rather than the whole domain. Why not just > create a subdomain for the ESP to use like marketing.example.com and > publish keys there? > > -Jim > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
On Sat 01/Apr/2023 13:17:55 +0200 Jim Fenton wrote: Not picking on Murray here, but his message was the most recent that talked about p=reject with respect to non-transactional email: On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote: If we use SHOULD NOT, as you suggest, there's an implication that there might be a valid reason for non-transactional mail to use "p=reject". Are we okay with that? We shouldn’t be assuming that mailing lists are the only cause of breakage for DMARC, and that transactional email is unimpacted by a p=reject policy. Some people use email forwarders so that they can have an email address that’s consistent if they change the email provider where their email is actually received. Sometimes they do this for “branding” reasons as well, such as to indicate their association with an organization or alumni association. Some of these email providers break DKIM signatures along the way. I have several such forwarding addresses, one of which is @alum.mit.edu, which breaks my DKIM signatures when I send a message to myself. If I used that address to receive transactional email from a domain with p=reject, and if my actual email provider enforced DMARC, I might not receive transactional email. + 1, saying that transactional mailers can set p=reject scot-free, or anyhow limiting who must not use DMARC is incorrect. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
On Fri 31/Mar/2023 18:16:28 +0200 Scott Kitterman wrote: On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely wrote: On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote: On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote: Does that mean that instead of "non-transactional mail flows" we could say "mail flows involving decades old software"? If you're going to put that label on MLMs, we need to add it to MTAs too. Oh and most of the protocols we're talking about. This is a pretty deep rabbit hole. Agreed. Yet, did you notice, for example, the steady decrease of X-MIME-Autoconverted breakage cases? The hype on security sped up software upgrading quite noticeably. Yes, but it didn't actively make the software less useful, so it's not really relevant to this case. Eh? Some auto-conversion filters were implemented by rather elegant filters able to decode and/or encode on the fly based on peer's capabilities. That stuff became less useful, if that's what you mean... Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Namespace delegation limits
On 2 Apr 2023, at 4:19, Douglas Foster wrote: > 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. Regardless of whether that’s a good idea, that would be an enormous change in the way DKIM works and would not happen given the scale of existing deployment. Besides, what’s the difference between this and just including the From address in the DKIM signature? I think what you are looking for is a way to delegate a key that is valid for only a specific address, rather than the whole domain. Why not just create a subdomain for the ESP to use like marketing.example.com and publish keys there? -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Namespace delegation limits
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 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
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 2 06:00:04 2023
Count| Bytes | Who ++--- 121 ( 100%) |1645959 ( 100%) | Total 17 (14.0%) | 269002 (16.3%) | Douglas Foster 17 (14.0%) | 136893 ( 8.3%) | Scott Kitterman 12 ( 9.9%) | 306262 (18.6%) | Alessandro Vesely 12 ( 9.9%) | 96729 ( 5.9%) | Murray S. Kucherawy 11 ( 9.1%) | 97059 ( 5.9%) | Barry Leiba 10 ( 8.3%) | 177053 (10.8%) | Todd Herr 10 ( 8.3%) | 90665 ( 5.5%) | Hector Santos 7 ( 5.8%) | 84460 ( 5.1%) | Dotzero 7 ( 5.8%) | 35420 ( 2.2%) | John Levine 4 ( 3.3%) | 102931 ( 6.3%) | Mark Alley 4 ( 3.3%) | 97183 ( 5.9%) | Brotman, Alex 2 ( 1.7%) | 58785 ( 3.6%) | Jesse Thompson 2 ( 1.7%) | 16153 ( 1.0%) | Pete Resnick 2 ( 1.7%) | 12380 ( 0.8%) | Jim Fenton 2 ( 1.7%) | 11545 ( 0.7%) | Benny Pedersen 1 ( 0.8%) | 50644 ( 3.1%) | Trent Adams 1 ( 0.8%) | 2795 ( 0.2%) | ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
