[dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Tuesday, April 25, 2023 2:27:18 PM EDT Scott Kitterman wrote: > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > I raised this issue in the DMARC session in Vienna, and have let it > > sit for a while so as not to derail other discussion. As we're pretty > > close to finished with the DMARCbis document, I'd like to raise it > > again, this time with specific proposed text for us to discuss. > > > > And so: > > > > OLD > > > >5.5.6. Decide If and When to Update DMARC Policy > > > >Once the Domain Owner is satisfied that it is properly authenticating > >all of its mail, then it is time to decide if it is appropriate to > >change the p= value in its DMARC record to p=quarantine or p=reject. > >Depending on its cadence for sending mail, it may take many months of > >consuming DMARC aggregate reports before a Domain Owner reaches the > >point where it is sure that it is properly authenticating all of its > >mail, and the decision on which p= value to use will depend on its > >needs. > > > > NEW > > > >5.5.6. Decide If and When to Update DMARC Policy > > > >Once the Domain Owner is satisfied that it is properly authenticating > >all of its mail, then it is time to decide if it is appropriate to > >change the p= value in its DMARC record to p=quarantine or p=reject. > >Depending on its cadence for sending mail, it may take many months of > >consuming DMARC aggregate reports before a Domain Owner reaches the > >point where it is sure that it is properly authenticating all of its > >mail, and the decision on which p= value to use will depend on its > >needs. > > > >It is important to understand that many domains may never use > >policies of “quarantine” or “reject”, and that these policies are > >intended not as goals, but as policies available for use when they > >are appropriate. In particular, “reject” is not intended for > >deployment in domains with users who send routine email, and its > >deployment in such domains can disrupt indirect mail flows and cause > >damage to operation of mailing lists and other forwarding services. > >This is discussed in [RFC7960] and in Section 5.8, below. The > >“reject” policy is best reserved for domains that send only > >transactional email that is not intended to be posted to mailing > >lists. > > > >To be explicitly clear: domains used for general-purpose email MUST > >NOT deploy a DMARC policy of p=reject. > > > > END > > > > I'm well aware that the MUST will *not* be followed by everyone, and > > that some domain owners will feel that they need to use p=reject, > > regardless. I think that's fine: the standard should specify what's > > right for interoperability, and I believe that improper use of > > p=reject is extremely harmful to interoperability... so "MUST" is > > correct here. And no one will be arrested or fined for choosing not > > to follow it. We should still say it, nonetheless. > > > > OK, have at it. > > I'm going to take another stab at this, starting back at the top of the > thread since things went off the rails. > > This is an attempt to see if we can focus in on getting some agreement on a > path forward on this question. If I may generalize for a moment, it seemed > to me that there are roughly two sets of perspectives on this (with > considerable variation within each set, of course). One set is from people > primarily focused on the security benefits associated with use of > restrictive DMARC policies such as p=reject. The other set is from people > primarily focused on the interoperability impacts associated with some > domains using such restrictive policies. > > For many, the security benefit is the primary purpose of DMARC. Without it, > it's relatively pointless. On the other hand, interoperability is a > significant reason the IETF exists. Without interoperability, the IETF is > relatively pointless. I am starting from the assumption that people are > prioritizing different things differently in good faith. Disagreement is > normal for something like this. > > For those of you that are new or perhaps relatively new to the IETF, I would > comment RFC 7282 to you for background, particularly paragraph 3 [1] as I > think it is a great discussion of the IETF way to work through a path > forward. > > The TLDR version is trying to find something we can live with, not something > we would prefer. There's clearly no overlap between the preferences of the > people in the two groups I described above. If anyone doubts that, I > encourage you to consult the list archive for the last month. The question > is, can we get to something that people from both groups can live with and > adequately address any technical points that are raised. > > My recollection is that a general formulation that I proposed had at least > some traction out of both groups: > > [some appropri
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
I was not proposing what other people should do, nor was I proposing a standards change. I was just observing that we always have choices (with supporting software.) In this case, if a remote correspondent cannot do acceptable TLS encryption, then the local correspondent always has the option of terminating the connection (cleanly), and communicating another way or not communicating at all. I was describing what was already in place. Our organization does not send outbound mail without encryption. If the correspondent cannot do TLS, we communicate by another method. Some MailFrom domains use encryption so reliably that you can block certain forms of impersonation simply by requiring encryption on inbound messages from those domains. No futures. No protocol redesign. Existing features of existing products. Doug Foster On Fri, Apr 28, 2023 at 5:24 PM Hector Santos wrote: > Douglas, > > In general, you can’t impose or mandate rules under PO RT 25 unsolicited, > unauthenticated sessions. You can do this with ESMTP AUTH a.k.a SUBMISSION > Protocol (RFC) which is Port 587. Under this port, you can mandate more > Authentication/Authorization than with Port 25 and not using ESMTP AUTH. > > So for example, for PCI, you must use A/A mechanisms probably under Port > 587 because it can be mandated. Not under Port 25. > > — > HLS > > > On Apr 27, 2023, at 7:04 AM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > There are options on TLS failure. > > Mandatory TLS is actually pretty common, since PCI DSS, HIPAA and GDBR > have all been interpreted as requiring TLS on email.For outbound mail, > our MTA is configured to drop the connection if encryption cannot be > established. I think this configuration option has become pretty common in > commercial products.Domains that cannot accept encrypted traffic are > handled with secure web relay (Zixmail or one of its many imitators.) In > the case of a report recipient that cannot accept TLS traffic, we would > simply drop the destination. > > For inbound mail, my organization has concluded that data security is the > responsibility of the sender, so we do accept unencrypted messages. > > By and large, mandatory TLS will be implemented consistently, rather than > on a specific message like a DMARC report, so I don't know how much needs > to be said in this document. > > Doug > > On Tue, Apr 25, 2023 at 12:29 PM John R. Levine wrote: > >> >> Since the only mechanism is mail and nobody's going to S/MIME encrypt >> >> their reports, I suggest just deleting it. >> > >> > TLS vs not TLS. >> >> I suppose, but that's not up to the report sender. If I say >> "rua=mailto:rep...@cruddy.org";, and the MX for cruddy.org doesn't do >> STARTTLS, what are you going to do? >> >> R's, >> John >> >> ___ >> 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 > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
Douglas, In general, you can’t impose or mandate TLS under PORT 25 unsolicited, unauthenticated sessions. You can do this with ESMTP AUTH a.k.a SUBMISSION Protocol (RFC6409) which is Port 587. Under this port, you can mandate more Authentication/Authorization and mail format correctness than with Port 25 and not using ESMTP AUTH. So for example, for PCI, you must use A/A mechanisms probably under Port 587 because it can be mandated. But not under Port 25. — HLS > On Apr 27, 2023, at 7:04 AM, Douglas Foster > wrote: > > There are options on TLS failure. > > Mandatory TLS is actually pretty common, since PCI DSS, HIPAA and GDBR have > all been interpreted as requiring TLS on email.For outbound mail, our MTA > is configured to drop the connection if encryption cannot be established. I > think this configuration option has become pretty common in commercial > products.Domains that cannot accept encrypted traffic are handled with > secure web relay (Zixmail or one of its many imitators.) In the case of a > report recipient that cannot accept TLS traffic, we would simply drop the > destination. > > For inbound mail, my organization has concluded that data security is the > responsibility of the sender, so we do accept unencrypted messages. > > By and large, mandatory TLS will be implemented consistently, rather than on > a specific message like a DMARC report, so I don't know how much needs to be > said in this document. > > Doug > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Proposed Updates for DMARCbis - Section 4.4.3 and New Appendix A.8
I would like to propose updates to the DMARCbis documentation, specifically for Section 4.4.3 and a new Appendix A.8. Please find the suggested revisions below. Your input would be greatly appreciated. It is just a starting point. Proposed update for Section 4.4.3: 4.4.3. Alignment and Extension Technologies DMARC can be extended to incorporate authentication and authorization mechanisms that aid in the evaluation of DMARC policy. Any new authentication extensions must facilitate domain identifier extraction to enable verification of alignment with the RFC5322.From domain. Authorization extensions address situations where the author domain differs from the signer domain, known as 3rd party signatures. The following Author::Signer domain authorization methods have been explored: DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures (ATPS) [RFC6541] Third-Party Authorization Label (TPA) [draft-otis-tpa-label-08] Mandatory Tags for DKIM Signatures [draft-levine-dkim-conditional-04] Delegating DKIM Signing Authority [draft-kucherawy-dkim-delegate-02] The first two methods are DNS-based, while the latter two are non-DNS-based. All share the common objective of authorizing the 3rd party signature. The ATPS proposal is the simplest method and has demonstrated success in practice by reducing false positive failure results when a valid and unverified but ATPS authorized 3rd party signer is present in a message. MDA receivers should consider using ATPS to verify 3rd party signatures. Proposed new Appendix A.8: A.8 Mailing List Servers Mailing List Servers (MLS) applications that are compliant with DMARC operations SHOULD adhere to the following guidelines for DMARC integration: Subscription and Submission Controls: MLS subscription processes should perform a DMARC check to determine if the subscribing or submitting email domain's DMARC policy is restrictive regarding mail integrity changes or 3rd party signatures. The MLS SHOULD only allow subscriptions and submissions from original domain policies that permit 3rd party signatures with a p=none policy. Message Content Integrity Change: List Servers that alter the message content SHOULD only do so for original domains with optional DKIM signing practices. If the List Server does not alter the message, it SHOULD NOT remove the signature, if present. Security Tear Down: The MLS SHOULD NOT compromise the author's security by changing the authorship address (From) domain. Instead, it should apply subscription/submission controls. However, if circumstances necessitate a From rewrite, the rewrite with a new address SHOULD maintain the same level of security as the original submission to avoid potential Replay and Display Name Attacks. Please let me know your thoughts on these proposed updates and whether they can be integrated into the DMARCbis documentation. Best regards, Hector Santos ___ 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 4/28/2023 5:19 AM, Alessandro Vesely wrote: > On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote: >> Mailing list changes to ameliorate damage due to DMARC are in no way an improvement. Absent DMARC, they would not be needed at all. > > +1 In my view, when an incomplete protocol is introduced, it creates gaps. If there are no guidelines for addressing these gaps in a graceful and elegant manner, solutions can vary widely. As developers, it's important to have the ability to make adjustments to our software. Here are a few suggestions to "ameliorate damages" caused by an incomplete protocol: 1) Address the gaps with proper protocol negotiation guidelines and a well-defined state machine. This includes addressing third-party signers and providing guidance for groupware, one-to-many, mailing lists, and newsletter distribution mailers. This would make the protocol more complete. 2) If option #1 is not viable and continues to be a non-starter with the editor of this standard track bis document, the document's status and endorsement become technically challenged in many ways. It then becomes critical to have a Field Operations status report on a) DMARC p=reject problems, b) current problem mitigations, and c) any new security threats introduced by the mitigations, particularly with a DMARC Security teardown. There aren't many options for MLS developers when dealing with an incomplete protocol. I have been developing mail software since the '80s, with products such as Silver Xpress, Platinum Xpress, Gold Xpress, and Wildcat! These early experiences have informed my current understanding of the challenges in integrating DMARC into systems. Regarding rewrite, we don't want to promote it, but it may now be necessary to describe it as a new potential "Display Name" security threat. However, there are legitimate situations where a rewrite is both technically necessary and ethically acceptable. For example: A MLM Newsletter list domain MUST have a From: domain example-biz.com for security. This is a read-only list, and only a few authorized submitters can post newsletters. They use their ESP's MUA to submit using their ESP's domain address. In this case, it is about the content payload, not the submitter. This is a legitimate situation where a complete rewrite of the incoming header is warranted. In the case of DMARC, it becomes necessary. The ESP's headers are removed, and the RFC5322 is applied for a secure, unambiguous result. It would be as if the customer logged into wcWEB and posted the newsletter directly in their MLM List storage area, but they prefer to do it via ESP email. Therefore, rewrite can be described as BAD when used intentionally to break down DMARC security or GOOD when used to create DMARC secured distribution. Thanks -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Friday, April 28, 2023 3:57:55 AM EDT Alessandro Vesely wrote: > On Fri 28/Apr/2023 05:14:16 +0200 Jesse Thompson wrote: > > On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: > >> On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: > >>>On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: > On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: > > Also, state that serious consideration includes testing p=quarantine; > > pct=0^H t=y. > I was going to say something similar but I think that it is implied by > section A.7>>> > >>>Actually, I like referencing A.7 here as a pointer. > >>> > >>>This achieves consensus on the rewrite objection. > >>> > >>>A.7 describes the rewrite without condoning it: > >>>[citation elided] > > Good note. I think it's called /lapsus calami/ when one ends up writing > something which wasn't supposed to be uttered. "The phenomena can be traced > back to incompletely suppressed psychical material, which, although pushed > away by consciousness, has nevertheless not been robbed of all capacity for > expressing itself" to cite Freud. > > >> I think we can describe what people are doing without placing a strong > >> value judgement on it, but I think we have to say we haven't assessed > >> all the associated interoperability impacts of it and at least mention > >> that 5321 says not to do it.> > > Restricting the "MUST NOT" to the context of 5321 achieves consensus, I > > think > RFC 5321 is not normative on that point. Section 3.9 says MLMs MUST change > the bounce address and SHOULD simply use the list. That's the only mustard > in the section. Changes to the header and the body are certainly not > encouraged, but the section ends saying: > > There exist mailing lists that perform additional, sometimes > extensive, modifications to a message and its envelope. Such mailing > lists need to be viewed as full MUAs, which accept a delivery and > post a new message. > > Now, *every* MUA I know rewrites From: when the user forwards a message. We've gone pretty far past where I was planning to go with this particular thread, so I'll leave this with two points: 1. MUA forwarding of a message is not a mailing list. 2. Read the main part of 3.9, not the sub-paragraph. Scott K ___ 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 Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote: Mailing list changes to ameliorate damage due to DMARC are in no way an improvement. Absent DMARC, they would not be needed at all. +1 Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu 27/Apr/2023 22:49:31 +0200 Scott Kitterman wrote: On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely wrote: On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote: On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? Me, for one. Because more than 98% of domains are going to fall into the description, however we word it, that statement makes the whole I-D nonsensical. Cannot we just tell the problem without MUSTard? In any case, using the complement of [some appropriate description] is certainly easier. For example: Forcing authentication into Internet mail by publishing restrictive DMARC policies breaks some well established patterns of usage. Publishing such policies is thus RECOMMENDED only for domains [in this other appropriate description]. Thanks. I understand your objection to be that the proposed description of the interoperability problems would apply to too many domains, regardless of the modifier we might use. Is that correct? Nearly. Too many would be 40%. 98% is practically all. Indeed, we're talking of mailboxes used by humans... I don't understand the technical issue associated with that objection. I get that you feel the construction is too negative, but I don't have a sense you think it's inaccurate. Focusing on the technical aspects of this, would you please help me understand what you think is technically incorrect about it? Perhaps MUST NOT would have some sense if DMARC were breaking a well known protocol. The established patterns of usage we break are in turn breaking some other RFCs, aren't they? Why would the applied workaround have less merit than the original hack, from a formal POV? I mean, if we stand by the letter of the protocols so much as to feel the need to say MUST NOT. If we think internet standards are meaningful, then if the applied work around directly conflicts with an internet standard (which From rewriting does: RFC 5321 and predecessors), then it he as substantially less merit. My recollection is that mailing lists were never standardized. They arose as a local-scoped alternative to Usenet, piggybacked on SMTP, following methods and traditions derived from common sense and convenience. The onset of From: rewriting is the latest step in their evolution, which testifies for their flexibility. From a user's perspective, From: rewriting in no way an improvement. Semantically, it poses the questions of authorship and identity of individuals with respect to the community. To the extent that DMARC marks a turning point in the email landscape, From: rewriting can be considered like sparks flying from the tire rim if the curve is too sharp. It'll settle eventually. Otherwise, we can try to stick to tradition and condemn DMARC, refusing to acknowledge the need for human authentication that seems to emerge. Why? To honor a tradition? To respect a standard that was never issued? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Fri 28/Apr/2023 05:14:16 +0200 Jesse Thompson wrote: On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: Also, state that serious consideration includes testing p=quarantine; pct=0^H t=y. I was going to say something similar but I think that it is implied by section A.7 Actually, I like referencing A.7 here as a pointer. This achieves consensus on the rewrite objection. A.7 describes the rewrite without condoning it: [citation elided] Good note. I think it's called /lapsus calami/ when one ends up writing something which wasn't supposed to be uttered. "The phenomena can be traced back to incompletely suppressed psychical material, which, although pushed away by consciousness, has nevertheless not been robbed of all capacity for expressing itself" to cite Freud. I think we can describe what people are doing without placing a strong value judgement on it, but I think we have to say we haven't assessed all the associated interoperability impacts of it and at least mention that 5321 says not to do it. Restricting the "MUST NOT" to the context of 5321 achieves consensus, I think RFC 5321 is not normative on that point. Section 3.9 says MLMs MUST change the bounce address and SHOULD simply use the list. That's the only mustard in the section. Changes to the header and the body are certainly not encouraged, but the section ends saying: There exist mailing lists that perform additional, sometimes extensive, modifications to a message and its envelope. Such mailing lists need to be viewed as full MUAs, which accept a delivery and post a new message. Now, *every* MUA I know rewrites From: when the user forwards a message. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
