[dmarc-ietf] Fwd: Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows
As you prepare for the meeting, I'm reposting the attached summary from April when I tried to explore where there might be some consensus on the interoperability question. In it, I tried out the generic formulation: > [some appropriate description] domains MUST NOT publish restrictive DMARC > policies due to interoperability issues I think Barry's new suggestion is broadly aligned to this approach, although less concise. Personally, I think the details need work, but I could generally live with it. We also need to address the subordinate protocol data reliability question and I still intend to write something up on that, but not today. Finally, we now have an Interoperability Issues section followed immediately by an Interoperability Considerations section. Maybe you could workshop different terms for one or both of those on the hallway track. Scott K --- Begin Message --- 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 thin
Re: [dmarc-ietf] Another p=reject text proposal
On Thu, Jul 6, 2023 at 3:00 PM Barry Leiba wrote: > That's fine, as long as we're all understanding that it's still just a > proposal and we'll be discussing it at IETF 117 and on the mailing list. > Absolutely. I just wanted to have a fresh draft in place before the cut off date, and today was as good a time for that as any. -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* todd.h...@valimail.com *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
As I've said before, I think we should specify what we think is right, and allow implementers to make their decisions. We can't and won't police them. b On Thu, Jul 6, 2023 at 2:59 PM Brotman, Alex wrote: > > I suspect the portion that instructs receivers to not act solely on p=reject > may be ignored by a fair set of receivers. I'm not necessarily opposed to > the language below, just that it seems odd to create language that we know > will be ignored. Additionally, I find it odd that we won't tell forwarders > how to munge messages to avoid this situation, but we will tell receivers how > to avoid this situation. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > > -Original Message- > > From: dmarc On Behalf Of Barry Leiba > > Sent: Thursday, July 6, 2023 10:55 AM > > To: IETF DMARC WG > > Subject: [dmarc-ietf] Another p=reject text proposal > > > > I had some off-list discussions with Seth, who was very much against my > > original > > proposed text, and he suggested an alternative organization that would be > > more > > palatable to him. I've attempted to set that out below. The idea is to > > remove the > > normative requirements about using p=reject from Sections 5.5.6 and 5.8, and > > instead put a broader discussion of the issues, along with the normative > > requirements, into a new "Interoperability Considerations" section. > > This makes it explicitly clear that any MUST/SHOULD stuff with regard to > > using > > and honoring p=reject is an issue of interoperating with existing Internet > > email > > features. I can accept that mechanism also, and so, below is my attempt at > > writing that proposal up. > > > > Barry > > > > - > > > > — Section 5.5.6 — > > > > ADD > >In making this decision it is important to understand the > >interoperability issues involved and problems that can result for > >mailing lists and for deliverability of legitimate mail. Those > >issues are discussed in detail in the Interoperability > >Considerations section [see Section x.x]. > > END > > > > — Section 5.8 — > > > > OLD > >Mail Receivers MAY choose to accept email that fails the DMARC > >mechanism check even if the published Domain Owner Assessment Policy > >is "reject". In particular, because of the considerations discussed > >in [RFC7960], it is important that Mail Receivers SHOULD NOT reject > >messages solely because of a published policy of "reject", but that > >they apply other knowledge and analysis to avoid situations such as > >rejection of legitimate messages sent in ways that DMARC cannot > >describe, harm to the operation of mailing lists, and similar. > > NEW > >Mail Receivers MAY choose to accept email that fails the DMARC > >mechanism check even if the published Domain Owner Assessment Policy > >is "reject". In particular, because of the considerations discussed > >in [RFC7960] and in the Interoperability Considerations section of > >this document [see Section x.x], it is important that Mail Receivers > >not reject messages solely because of a published policy of "reject", > >but that they apply other knowledge and analysis to avoid situations > >such as rejection of legitimate messages sent in ways that DMARC > >cannot describe, harm to the operation of mailing lists, and similar. > > END > > > > — New section — > > > > ADD > > x.x Interoperability Considerations > > > >As discussed in “Interoperability Issues between DMARC and Indirect > >Email Flows [RFC7960], use of p=reject can be incompatible with and > >cause interoperability problems to indirect message flows such as > >“alumni forwarders”, role-based email aliases, and mailing lists > >across the Internet. > > > >Even a domain that expects to send only targeted messages to > >account holders — a bank, for example — could have account > >holders using addresses such as jo...@alumni.example.edu (an > >address that relays the messages to another address with a real > >mailbox) or finance@association.example (a role-based address that > >does similar relaying for the current head of finance at the > >association). When such mail is delivered to the actual recipient > >mailbox, it will necessarily fail SPF checks, as the incoming > >IP address will be that of example.edu or association.example, and > >not an address authorized for the sending domain. DKIM signatures > >will generally remain valid in these relay situations. > > > > It is therefore critical that domains that publish p=reject > > MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures > > to their messages. > > > >Domains that have general users who send routine email are > >particularly likely to create interoperability issues if they > >publish p=reject
[dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-28.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Domain-based Message Authentication, Reporting & Conformance (DMARC) WG of the IETF. Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Authors : Todd M. Herr John Levine Filename: draft-ietf-dmarc-dmarcbis-28.txt Pages : 72 Date: 2023-07-06 Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-28 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
That's fine, as long as we're all understanding that it's still just a proposal and we'll be discussing it at IETF 117 and on the mailing list. Barry On Thu, Jul 6, 2023 at 2:07 PM Todd Herr wrote: > I'll prepare a new rev incorporating this proposed text (and some other > unrelated stuff that's been lying fallow for a few months) and release it > today. > > On Thu, Jul 6, 2023 at 12:02 PM John Levine wrote: > >> It appears that Barry Leiba said: >> >This makes it explicitly clear that any MUST/SHOULD stuff with regard >> >to using and honoring p=reject is an issue of interoperating with >> >existing Internet email features. I can accept that mechanism also, >> >and so, below is my attempt at writing that proposal up. >> >> This seems about as good as we're going to get. >> >> I agree that advice about From: munging and anything else about how >> forwarders might rewrite messages to circumvent DMARC is wildly out of >> scope. We currently don't mention ARC at all. Dunno if it's worth >> a non-normative pointer somewhere. >> >> R's, >> John >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > > *Todd Herr * | Technical Director, Standards & Ecosystem > *e:* todd.h...@valimail.com > *p:* 703-220-4153 > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > ___ > 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] Another p=reject text proposal
I suspect the portion that instructs receivers to not act solely on p=reject may be ignored by a fair set of receivers. I'm not necessarily opposed to the language below, just that it seems odd to create language that we know will be ignored. Additionally, I find it odd that we won't tell forwarders how to munge messages to avoid this situation, but we will tell receivers how to avoid this situation. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Barry Leiba > Sent: Thursday, July 6, 2023 10:55 AM > To: IETF DMARC WG > Subject: [dmarc-ietf] Another p=reject text proposal > > I had some off-list discussions with Seth, who was very much against my > original > proposed text, and he suggested an alternative organization that would be more > palatable to him. I've attempted to set that out below. The idea is to > remove the > normative requirements about using p=reject from Sections 5.5.6 and 5.8, and > instead put a broader discussion of the issues, along with the normative > requirements, into a new "Interoperability Considerations" section. > This makes it explicitly clear that any MUST/SHOULD stuff with regard to using > and honoring p=reject is an issue of interoperating with existing Internet > email > features. I can accept that mechanism also, and so, below is my attempt at > writing that proposal up. > > Barry > > - > > — Section 5.5.6 — > > ADD >In making this decision it is important to understand the >interoperability issues involved and problems that can result for >mailing lists and for deliverability of legitimate mail. Those >issues are discussed in detail in the Interoperability >Considerations section [see Section x.x]. > END > > — Section 5.8 — > > OLD >Mail Receivers MAY choose to accept email that fails the DMARC >mechanism check even if the published Domain Owner Assessment Policy >is "reject". In particular, because of the considerations discussed >in [RFC7960], it is important that Mail Receivers SHOULD NOT reject >messages solely because of a published policy of "reject", but that >they apply other knowledge and analysis to avoid situations such as >rejection of legitimate messages sent in ways that DMARC cannot >describe, harm to the operation of mailing lists, and similar. > NEW >Mail Receivers MAY choose to accept email that fails the DMARC >mechanism check even if the published Domain Owner Assessment Policy >is "reject". In particular, because of the considerations discussed >in [RFC7960] and in the Interoperability Considerations section of >this document [see Section x.x], it is important that Mail Receivers >not reject messages solely because of a published policy of "reject", >but that they apply other knowledge and analysis to avoid situations >such as rejection of legitimate messages sent in ways that DMARC >cannot describe, harm to the operation of mailing lists, and similar. > END > > — New section — > > ADD > x.x Interoperability Considerations > >As discussed in “Interoperability Issues between DMARC and Indirect >Email Flows [RFC7960], use of p=reject can be incompatible with and >cause interoperability problems to indirect message flows such as >“alumni forwarders”, role-based email aliases, and mailing lists >across the Internet. > >Even a domain that expects to send only targeted messages to >account holders — a bank, for example — could have account >holders using addresses such as jo...@alumni.example.edu (an >address that relays the messages to another address with a real >mailbox) or finance@association.example (a role-based address that >does similar relaying for the current head of finance at the >association). When such mail is delivered to the actual recipient >mailbox, it will necessarily fail SPF checks, as the incoming >IP address will be that of example.edu or association.example, and >not an address authorized for the sending domain. DKIM signatures >will generally remain valid in these relay situations. > > It is therefore critical that domains that publish p=reject > MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures > to their messages. > >Domains that have general users who send routine email are >particularly likely to create interoperability issues if they >publish p=reject. For example, domains that serve as mailbox hosts >and give out email addresses to the general public are best advised >to delay adoption of p=reject until the authentication ecosystem >becomes more mature and deliverability issues are better resolved. > >In particular, if users in p=reject domains post messages to >mailing lists on the Internet, those messages can cause operat
Re: [dmarc-ietf] Another p=reject text proposal
I'll prepare a new rev incorporating this proposed text (and some other unrelated stuff that's been lying fallow for a few months) and release it today. On Thu, Jul 6, 2023 at 12:02 PM John Levine wrote: > It appears that Barry Leiba said: > >This makes it explicitly clear that any MUST/SHOULD stuff with regard > >to using and honoring p=reject is an issue of interoperating with > >existing Internet email features. I can accept that mechanism also, > >and so, below is my attempt at writing that proposal up. > > This seems about as good as we're going to get. > > I agree that advice about From: munging and anything else about how > forwarders might rewrite messages to circumvent DMARC is wildly out of > scope. We currently don't mention ARC at all. Dunno if it's worth > a non-normative pointer somewhere. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* todd.h...@valimail.com *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
It appears that Barry Leiba said: >This makes it explicitly clear that any MUST/SHOULD stuff with regard >to using and honoring p=reject is an issue of interoperating with >existing Internet email features. I can accept that mechanism also, >and so, below is my attempt at writing that proposal up. This seems about as good as we're going to get. I agree that advice about From: munging and anything else about how forwarders might rewrite messages to circumvent DMARC is wildly out of scope. We currently don't mention ARC at all. Dunno if it's worth a non-normative pointer somewhere. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Questions regarding RFC 8617
Hey Douglas, Thank you for your response. Full disclosure this is the subject of my talk I’ll be presenting at defcon next month, I thought I’d reach out cause the more I dig into this the more nuance I find. Just to clarify, is it possible having this “bad” ARC header is skewing the final spam score of the email when it hits the final email service provider ? I don’t see anything in the RFC on how email services should use ARC in relation to calculating the spam score of an email. From my understanding It seems ARC will pass as long as the chains integrity isn’t compromised *not* because of bad values in a header like this correct? On Thu, Jul 6, 2023 at 05:02, Douglas Foster <[dougfoster.emailstanda...@gmail.com](mailto:On Thu, Jul 6, 2023 at 05:02, Douglas Foster < wrote: > "Cloudfare" is not qualified, so it does not credibly mean "This message was > submitted by user Cloudfare with his correct password.". This guess can be > validated by checking where the ARC set appears relative to the Received > chain. > > Since we know that Cloudfare is a large hosting service, I suspect the sender > is asserting, "I am sending this messages through Cloudfare after logging > into their server with a username and password." This is a misuse of ARC and > this initial ARC set should be ignored. > > Doug > > On Wed, Jul 5, 2023, 10:15 PM Marcello > wrote: > >> Hey there, >> >> I was hoping to run a few questions by the authors of the ARC protocol. >> >> Long story short, I've discovered an email transaction service that always >> claims "auth=pass" in it's AAR header, see the following example: >> >> ARC-Authentication-Results: i=1; rspamd-9fcc56855-j2crh; >> auth=pass smtp.auth=cloudflare smtp.mailfrom=t...@example.com >> This is how their AAR header always looks like regardless of the senders >> domain SPF/DMARC/DKIM record. My questions here are: >> >> - is "auth=pass" a valid property in the AAR header? RFC 8617 seems to >> indicate you can technically put anything you want but all the examples I've >> seen are different and actually have SPF/DMARC/DKIM check results. (e.g. >> spf=pass etc..) >> - Can an ARC chain be considered valid in the case where the first hop (i=1) >> has the above AAR header and doesn't actually check SPF/DMARC/DKIM of the >> sender domain? >> - How should the final Email service provider treat an email with an AAR >> header like the above? >> - Should not having SPF/DMARC/DKIM checks in the AAR header result in an >> arc=fail? >> >> Thank you for your time. >> Marcello >> >> ___ >> 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] Another p=reject text proposal
I don't think this is the place to tell mailing lists what to do, and that's all discussed in Section 4.1.3 of RFC 7960. Barry On Thu, Jul 6, 2023 at 11:48 AM Alessandro Vesely wrote: > > Hi, > > the only issue I'd put about the new section is that it doesn't mention From: > munging. Isn't that practice widespread enough that it deserves being > considered? > > > Best > Ale > > > On Thu 06/Jul/2023 16:55:02 +0200 Barry Leiba wrote: > > I had some off-list discussions with Seth, who was very much against > > my original proposed text, and he suggested an alternative > > organization that would be more palatable to him. I've attempted to > > set that out below. The idea is to remove the normative requirements > > about using p=reject from Sections 5.5.6 and 5.8, and instead put a > > broader discussion of the issues, along with the normative > > requirements, into a new "Interoperability Considerations" section. > > This makes it explicitly clear that any MUST/SHOULD stuff with regard > > to using and honoring p=reject is an issue of interoperating with > > existing Internet email features. I can accept that mechanism also, > > and so, below is my attempt at writing that proposal up. > > > > Barry > > > > - > > > > — Section 5.5.6 — > > > > ADD > > In making this decision it is important to understand the > > interoperability issues involved and problems that can result for > > mailing lists and for deliverability of legitimate mail. Those > > issues are discussed in detail in the Interoperability > > Considerations section [see Section x.x]. > > END > > > > — Section 5.8 — > > > > OLD > > Mail Receivers MAY choose to accept email that fails the DMARC > > mechanism check even if the published Domain Owner Assessment Policy > > is "reject". In particular, because of the considerations discussed > > in [RFC7960], it is important that Mail Receivers SHOULD NOT reject > > messages solely because of a published policy of "reject", but that > > they apply other knowledge and analysis to avoid situations such as > > rejection of legitimate messages sent in ways that DMARC cannot > > describe, harm to the operation of mailing lists, and similar. > > NEW > > Mail Receivers MAY choose to accept email that fails the DMARC > > mechanism check even if the published Domain Owner Assessment Policy > > is "reject". In particular, because of the considerations discussed > > in [RFC7960] and in the Interoperability Considerations section of > > this document [see Section x.x], it is important that Mail Receivers > > not reject messages solely because of a published policy of "reject", > > but that they apply other knowledge and analysis to avoid situations > > such as rejection of legitimate messages sent in ways that DMARC > > cannot describe, harm to the operation of mailing lists, and similar. > > END > > > > — New section — > > > > ADD > > x.x Interoperability Considerations > > > > As discussed in “Interoperability Issues between DMARC and Indirect > > Email Flows [RFC7960], use of p=reject can be incompatible with and > > cause interoperability problems to indirect message flows such as > > “alumni forwarders”, role-based email aliases, and mailing lists > > across the Internet. > > > > Even a domain that expects to send only targeted messages to > > account holders — a bank, for example — could have account > > holders using addresses such as jo...@alumni.example.edu (an > > address that relays the messages to another address with a real > > mailbox) or finance@association.example (a role-based address that > > does similar relaying for the current head of finance at the > > association). When such mail is delivered to the actual recipient > > mailbox, it will necessarily fail SPF checks, as the incoming > > IP address will be that of example.edu or association.example, and > > not an address authorized for the sending domain. DKIM signatures > > will generally remain valid in these relay situations. > > > >It is therefore critical that domains that publish p=reject > >MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures > >to their messages. > > > > Domains that have general users who send routine email are > > particularly likely to create interoperability issues if they > > publish p=reject. For example, domains that serve as mailbox hosts > > and give out email addresses to the general public are best advised > > to delay adoption of p=reject until the authentication ecosystem > > becomes more mature and deliverability issues are better resolved. > > > > In particular, if users in p=reject domains post messages to > > mailing lists on the Internet, those messages can cause operational > > problems for the m
Re: [dmarc-ietf] Another p=reject text proposal
Hi, the only issue I'd put about the new section is that it doesn't mention From: munging. Isn't that practice widespread enough that it deserves being considered? Best Ale On Thu 06/Jul/2023 16:55:02 +0200 Barry Leiba wrote: I had some off-list discussions with Seth, who was very much against my original proposed text, and he suggested an alternative organization that would be more palatable to him. I've attempted to set that out below. The idea is to remove the normative requirements about using p=reject from Sections 5.5.6 and 5.8, and instead put a broader discussion of the issues, along with the normative requirements, into a new "Interoperability Considerations" section. This makes it explicitly clear that any MUST/SHOULD stuff with regard to using and honoring p=reject is an issue of interoperating with existing Internet email features. I can accept that mechanism also, and so, below is my attempt at writing that proposal up. Barry - — Section 5.5.6 — ADD In making this decision it is important to understand the interoperability issues involved and problems that can result for mailing lists and for deliverability of legitimate mail. Those issues are discussed in detail in the Interoperability Considerations section [see Section x.x]. END — Section 5.8 — OLD Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960], it is important that Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject", but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar. NEW Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960] and in the Interoperability Considerations section of this document [see Section x.x], it is important that Mail Receivers not reject messages solely because of a published policy of "reject", but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar. END — New section — ADD x.x Interoperability Considerations As discussed in “Interoperability Issues between DMARC and Indirect Email Flows [RFC7960], use of p=reject can be incompatible with and cause interoperability problems to indirect message flows such as “alumni forwarders”, role-based email aliases, and mailing lists across the Internet. Even a domain that expects to send only targeted messages to account holders — a bank, for example — could have account holders using addresses such as jo...@alumni.example.edu (an address that relays the messages to another address with a real mailbox) or finance@association.example (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will necessarily fail SPF checks, as the incoming IP address will be that of example.edu or association.example, and not an address authorized for the sending domain. DKIM signatures will generally remain valid in these relay situations. It is therefore critical that domains that publish p=reject MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures to their messages. Domains that have general users who send routine email are particularly likely to create interoperability issues if they publish p=reject. For example, domains that serve as mailbox hosts and give out email addresses to the general public are best advised to delay adoption of p=reject until the authentication ecosystem becomes more mature and deliverability issues are better resolved. In particular, if users in p=reject domains post messages to mailing lists on the Internet, those messages can cause operational problems for the mailing lists and for the subscribers to those lists, as explained below and in [RFC7960]. It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject. Domains that choose to publish p=reject SHOULD implement policies that their users not post to Internet mailing lists. As noted in [Section 5.8], receiving domains need to apply more analysis than just DMARC evaluation in their disposition of incoming messages. An example of
Re: [dmarc-ietf] Another p=reject text proposal
Whatever works within our constraints. It is certainly an interoperability consideration, and evaluators will have a hard time reverse engineering why the signature fails verification. df On Thu, Jul 6, 2023, 11:25 AM Barry Leiba wrote: > > This language works well for me. > > Excellent; thanks. > > > I suggest adding some language about why MTAs should not rearrange > message headers or MIME > > sections, even though earlier documents grant permission to do so. > > > > Additionally, when adding headers, an MTA must add them at the top if > (a) the header type is > > included in any verifiable signature, (b) the header is officially > labelled a trace header, or (c) the > > MTA chooses not to match the added header type to existing signatures > (ARC or DKIM) > > If you're talking about something related to the sending domain not > doing that after DKIM signing, we could say that as part of the "use > DKIM and do it correctly" part. If you're talking about MTAs further > along the path, that's out of scope here, at least in a normative > sense. We could say, informatively, that those practices break DKIM > signatures and thus hurt DMARC. But we can't place normative > requirements on MTAs that are not implementing DMARC. > > Barry > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> This language works well for me. Excellent; thanks. > I suggest adding some language about why MTAs should not rearrange message > headers or MIME > sections, even though earlier documents grant permission to do so. > > Additionally, when adding headers, an MTA must add them at the top if (a) the > header type is > included in any verifiable signature, (b) the header is officially labelled a > trace header, or (c) the > MTA chooses not to match the added header type to existing signatures (ARC or > DKIM) If you're talking about something related to the sending domain not doing that after DKIM signing, we could say that as part of the "use DKIM and do it correctly" part. If you're talking about MTAs further along the path, that's out of scope here, at least in a normative sense. We could say, informatively, that those practices break DKIM signatures and thus hurt DMARC. But we can't place normative requirements on MTAs that are not implementing DMARC. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC session agenda for IETF 117
> For clarity: When you say, "AD will call consensus on this issue", you mean > after the results of the discussion > are brought to the list and reviewed by the working group, not at the > meeting, right? Yes, correct. I wanted to make it clear that Seth and I both have a conflict on this, and neither of us can be the one calling consensus. (I honestly think that either of us would actually do it fairly, but we really do need to stay away from that...) > Also, I expect to have a proposal on protocol reliability related to the > "drop SPF" discussion, in the next day or three. Excellent; thanks! Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
This language works well for me. I suggest adding some language about why MTAs should not rearrange message headers or MIME sections, even though earlier documents grant permission to do so. Additionally, when adding headers, an MTA must add them at the top if (a) the header type is included in any verifiable signature, (b) the header is officially labelled a trace header, or (c) the MTA chooses not to match the added header type to existing signatures (ARC or DKIM) df On Thu, Jul 6, 2023, 10:55 AM Barry Leiba wrote: > I had some off-list discussions with Seth, who was very much against > my original proposed text, and he suggested an alternative > organization that would be more palatable to him. I've attempted to > set that out below. The idea is to remove the normative requirements > about using p=reject from Sections 5.5.6 and 5.8, and instead put a > broader discussion of the issues, along with the normative > requirements, into a new "Interoperability Considerations" section. > This makes it explicitly clear that any MUST/SHOULD stuff with regard > to using and honoring p=reject is an issue of interoperating with > existing Internet email features. I can accept that mechanism also, > and so, below is my attempt at writing that proposal up. > > Barry > > > - > > — Section 5.5.6 — > > ADD >In making this decision it is important to understand the >interoperability issues involved and problems that can result for >mailing lists and for deliverability of legitimate mail. Those >issues are discussed in detail in the Interoperability >Considerations section [see Section x.x]. > END > > — Section 5.8 — > > OLD >Mail Receivers MAY choose to accept email that fails the DMARC >mechanism check even if the published Domain Owner Assessment Policy >is "reject". In particular, because of the considerations discussed >in [RFC7960], it is important that Mail Receivers SHOULD NOT reject >messages solely because of a published policy of "reject", but that >they apply other knowledge and analysis to avoid situations such as >rejection of legitimate messages sent in ways that DMARC cannot >describe, harm to the operation of mailing lists, and similar. > NEW >Mail Receivers MAY choose to accept email that fails the DMARC >mechanism check even if the published Domain Owner Assessment Policy >is "reject". In particular, because of the considerations discussed >in [RFC7960] and in the Interoperability Considerations section of >this document [see Section x.x], it is important that Mail Receivers >not reject messages solely because of a published policy of "reject", >but that they apply other knowledge and analysis to avoid situations >such as rejection of legitimate messages sent in ways that DMARC >cannot describe, harm to the operation of mailing lists, and similar. > END > > — New section — > > ADD > x.x Interoperability Considerations > >As discussed in “Interoperability Issues between DMARC and Indirect >Email Flows [RFC7960], use of p=reject can be incompatible with and >cause interoperability problems to indirect message flows such as >“alumni forwarders”, role-based email aliases, and mailing lists >across the Internet. > >Even a domain that expects to send only targeted messages to >account holders — a bank, for example — could have account >holders using addresses such as jo...@alumni.example.edu (an >address that relays the messages to another address with a real >mailbox) or finance@association.example (a role-based address that >does similar relaying for the current head of finance at the >association). When such mail is delivered to the actual recipient >mailbox, it will necessarily fail SPF checks, as the incoming >IP address will be that of example.edu or association.example, and >not an address authorized for the sending domain. DKIM signatures >will generally remain valid in these relay situations. > > It is therefore critical that domains that publish p=reject > MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures > to their messages. > >Domains that have general users who send routine email are >particularly likely to create interoperability issues if they >publish p=reject. For example, domains that serve as mailbox hosts >and give out email addresses to the general public are best advised >to delay adoption of p=reject until the authentication ecosystem >becomes more mature and deliverability issues are better resolved. > >In particular, if users in p=reject domains post messages to >mailing lists on the Internet, those messages can cause operational >problems for the mailing lists and for the subscribers to those >lists, as explained below and in [RFC7960]. > > It is therefore critical th
Re: [dmarc-ietf] DMARC session agenda for IETF 117
For clarity: When you say, "AD will call consensus on this issue", you mean after the results of the discussion are brought to the list and reviewed by the working group, not at the meeting, right? Also, I expect to have a proposal on protocol reliability related to the "drop SPF" discussion, in the next day or three. Scott K On July 6, 2023 3:00:23 PM UTC, Barry Leiba wrote: >Below is the agenda I am posting for the session at IETF 117. >Comments, changes, and additions are welcome; please post them here. > >Barry > >--- > >DMARC working group session at IETF 117 >Friday, 28 July, 2023 — 12:00-13:30 PDT (UTC-7) > >- Introduction and administration >- Document status > >- Discussion of p=reject: > - What’s needed to deal with the indirect mail flow problems? > - Options currently open: >- No change to current text >- Move ARC to Standards Track (need more data) >- Scott Kitterman’s proposed text >- Barry Leiba’s proposed text (new Interoperability Considerations section) > - AD will call consensus on this issue > >- Discussion of SPF use in DMARC > - There was a proposal to remove SPF from DMARC > - The proposal is *only* related to use of SPF *in DMARC* > - Options currently open: >- No change to current text >- Simply remove SPF from DMARC consideration >- Add a DMARC record tag to specify use of SPF, DKIM, or either > - Do we also add “both must align”? > >- Any other business > >--- > >___ >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-ietf] DMARC session agenda for IETF 117
Below is the agenda I am posting for the session at IETF 117. Comments, changes, and additions are welcome; please post them here. Barry --- DMARC working group session at IETF 117 Friday, 28 July, 2023 — 12:00-13:30 PDT (UTC-7) - Introduction and administration - Document status - Discussion of p=reject: - What’s needed to deal with the indirect mail flow problems? - Options currently open: - No change to current text - Move ARC to Standards Track (need more data) - Scott Kitterman’s proposed text - Barry Leiba’s proposed text (new Interoperability Considerations section) - AD will call consensus on this issue - Discussion of SPF use in DMARC - There was a proposal to remove SPF from DMARC - The proposal is *only* related to use of SPF *in DMARC* - Options currently open: - No change to current text - Simply remove SPF from DMARC consideration - Add a DMARC record tag to specify use of SPF, DKIM, or either - Do we also add “both must align”? - Any other business --- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Another p=reject text proposal
I had some off-list discussions with Seth, who was very much against my original proposed text, and he suggested an alternative organization that would be more palatable to him. I've attempted to set that out below. The idea is to remove the normative requirements about using p=reject from Sections 5.5.6 and 5.8, and instead put a broader discussion of the issues, along with the normative requirements, into a new "Interoperability Considerations" section. This makes it explicitly clear that any MUST/SHOULD stuff with regard to using and honoring p=reject is an issue of interoperating with existing Internet email features. I can accept that mechanism also, and so, below is my attempt at writing that proposal up. Barry - — Section 5.5.6 — ADD In making this decision it is important to understand the interoperability issues involved and problems that can result for mailing lists and for deliverability of legitimate mail. Those issues are discussed in detail in the Interoperability Considerations section [see Section x.x]. END — Section 5.8 — OLD Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960], it is important that Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject", but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar. NEW Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960] and in the Interoperability Considerations section of this document [see Section x.x], it is important that Mail Receivers not reject messages solely because of a published policy of "reject", but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar. END — New section — ADD x.x Interoperability Considerations As discussed in “Interoperability Issues between DMARC and Indirect Email Flows [RFC7960], use of p=reject can be incompatible with and cause interoperability problems to indirect message flows such as “alumni forwarders”, role-based email aliases, and mailing lists across the Internet. Even a domain that expects to send only targeted messages to account holders — a bank, for example — could have account holders using addresses such as jo...@alumni.example.edu (an address that relays the messages to another address with a real mailbox) or finance@association.example (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will necessarily fail SPF checks, as the incoming IP address will be that of example.edu or association.example, and not an address authorized for the sending domain. DKIM signatures will generally remain valid in these relay situations. It is therefore critical that domains that publish p=reject MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures to their messages. Domains that have general users who send routine email are particularly likely to create interoperability issues if they publish p=reject. For example, domains that serve as mailbox hosts and give out email addresses to the general public are best advised to delay adoption of p=reject until the authentication ecosystem becomes more mature and deliverability issues are better resolved. In particular, if users in p=reject domains post messages to mailing lists on the Internet, those messages can cause operational problems for the mailing lists and for the subscribers to those lists, as explained below and in [RFC7960]. It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject. Domains that choose to publish p=reject SHOULD implement policies that their users not post to Internet mailing lists. As noted in [Section 5.8], receiving domains need to apply more analysis than just DMARC evaluation in their disposition of incoming messages. An example of the consequences of honoring p=reject without further anaysis is that rejecting messages that have been relayed by a mailing list can cause your own users to have their subscriptions to that mailing list cancelled by the list software’s automated handling of such rejections — it l
Re: [dmarc-ietf] Questions regarding RFC 8617
"Cloudfare" is not qualified, so it does not credibly mean "This message was submitted by user Cloudfare with his correct password.". This guess can be validated by checking where the ARC set appears relative to the Received chain. Since we know that Cloudfare is a large hosting service, I suspect the sender is asserting, "I am sending this messages through Cloudfare after logging into their server with a username and password." This is a misuse of ARC and this initial ARC set should be ignored. Doug On Wed, Jul 5, 2023, 10:15 PM Marcello wrote: > Hey there, > > I was hoping to run a few questions by the authors of the ARC protocol. > > Long story short, I've discovered an email transaction service that always > claims "auth=pass" in it's AAR header, see the following example: > > ARC-Authentication-Results: i=1; rspamd-9fcc56855-j2crh; > auth=pass smtp.auth=cloudflare > smtp.mailfrom=t...@example.com > > > This is how their AAR header *always* looks like regardless of the > senders domain SPF/DMARC/DKIM record. My questions here are: > > >1. is "auth=pass" a valid property in the AAR header? RFC 8617 seems >to indicate you can technically put anything you want but all the examples >I've seen are different and actually have SPF/DMARC/DKIM check results. >(e.g. spf=pass etc..) >2. Can an ARC chain be considered valid in the case where the first >hop (i=1) has the above AAR header and doesn't actually check >SPF/DMARC/DKIM of the sender domain? >3. How should the final Email service provider treat an email with an >AAR header like the above? >4. Should not having SPF/DMARC/DKIM checks in the AAR header result in >an arc=fail? > > > Thank you for your time. > > Marcello > > ___ > 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
