Re: [dmarc-ietf] Another p=reject text proposal
On Sat, Aug 12, 2023, at 11:48 AM, John Levine wrote: > It appears that Jesse Thompson said: > >> This of course requires that the recipient SMTP server can't simply > >> reject the incoming email after the MAIL FROM because SPF checks do > >> not match, they actually need to receive the email so they can check > >> ARC and DKIM headers... > > > >During my 19 year career we used software built by Ned Freed. It was > >perfectly capable of evaluating full content (as well as > >integrating with 3rd party evaluation software) and return an appropriate > >SMTP response after DATA. Why is it still so difficult? > > I am in yet another argument with a guy who is complaining that he's > not getting forwarded mail, I point out that he's rejecting on SPF > failure so that's not a bug, it's what he has told his system to do, > and he insists it's my fault. For some reason this attitude is > unusually common in mail systems in central Europe. The guy presumably rejects based on SPF during MAIL FROM, right? Rejecting due to DMARC missing SPF alignment would need to wait until DKIM alignment and other factors are known would need to occur after DATA. Sounds like this could be spelled out as a best practice, if it isn't. > To reiterate the obvious, you can't do DMARC without processing the > entire message during the SMTP session at least enough to check the > DKIM signatures. No sensible mail system rejects on SPF failure (other > than bare -all for no mail), because the error rate is so huge. > > A very long time ago people tried to minimize the work in the SMTP > daemon because there were small fixed size connection tables and on > systems without shared libraries, many copies of the daemon could > cause a lot of swapping. These days the connection table never fills > up, my SMTP daemon uses about 30 shared libraries, and my decade old > server can handle 100 connections and barely notices the load. So, > yeah, you can do it all in the SMTP daemon and in practice everyone > does now. I get that there is a lot of legacy code to support which will take forever to change. If it's a matter of requiring increased memory overhead (etc) to get the desired result of being able to consider complete context before issuing the most appropriate SMTP response after DATA, it is technically possible today and is in the receiver's best interest to invest in the additional cost of doing it. Another best practice? I suppose that if per-RCPT considerations are factored into the SMTP response after DATA, it implies that senders will be able to achieve the best interpretation of SMTP response messages by sending to a single recipient per transaction (which sounds like is needed for some of the potential implementations for the "identification of the RCPT TO" for fixing DKIM Replay) Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
It appears that Jesse Thompson said: >> This of course requires that the recipient SMTP server can't simply >> reject the incoming email after the MAIL FROM because SPF checks do >> not match, they actually need to receive the email so they can check >> ARC and DKIM headers... > >During my 19 year career we used software built by Ned Freed. It was perfectly >capable of evaluating full content (as well as >integrating with 3rd party evaluation software) and return an appropriate SMTP >response after DATA. Why is it still so difficult? I am in yet another argument with a guy who is complaining that he's not getting forwarded mail, I point out that he's rejecting on SPF failure so that's not a bug, it's what he has told his system to do, and he insists it's my fault. For some reason this attitude is unusually common in mail systems in central Europe. To reiterate the obvious, you can't do DMARC without processing the entire message during the SMTP session at least enough to check the DKIM signatures. No sensible mail system rejects on SPF failure (other than bare -all for no mail), because the error rate is so huge. A very long time ago people tried to minimize the work in the SMTP daemon because there were small fixed size connection tables and on systems without shared libraries, many copies of the daemon could cause a lot of swapping. These days the connection table never fills up, my SMTP daemon uses about 30 shared libraries, and my decade old server can handle 100 connections and barely notices the load. So, yeah, you can do it all in the SMTP daemon and in practice everyone does now. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
I'm woefully behind on this list. Apologies if these points have already been made. On Wed, Jul 19, 2023, at 4:42 PM, Tero Kivinen wrote: > Wei Chuang writes: > > 2) The proposed language calls out "“alumni forwarders”, role-based email > > aliases, and mailing lists" for consideration by receivers. How should > > receivers be aware that traffic failing authentication should be > > reconsidered? > > Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] > > call out more strongly the application of those List-id headers? Can > > something be done so that receivers can identify the other scenarios e.g. > > role-based email aliases and alumni-forwarders? > > For alumni forwarders / role-based forwarders things are different, as > users who set those up, actually knows who does the forwarding, and > they themself recognize that emails coming to those addresses are > important to them, and they also trust (university etc) the one doing > forwarding. > > So if the alumni forwarder / role-based forwarder adds ARC signatures, > then the final recipient can whitelist that ARC signer in their setup > and say that the policy code that checks the SPF/DKIM/DMARC results > can fully trust the signed ARC authentication results from that > signer. As someone who provided mail services for a R1 research university for 19 years... Pretty much all universities have migrated to O365 or Gmail due to economic factors, which have tiered pricing for hosting legacy addresses that use the same domain as the active faculty/students. Researchers and grad students want their old address to remain active because it what they publish on papers, and they want the mail sent to their old address to follow them to their new academic institution(s) and employer(s) when they move on. Yes, the Alumni division also offers a different domain for alumni, hosted by admins who don't know much about email interoperability, but that is just another domain hosted on Gmail, so the forwarding problem is Gmail's so solve, as much as it is a problem for the university to solve for allowing forwarding for active/former faculty/students. > This of course requires that the recipient SMTP server can't simply > reject the incoming email after the MAIL FROM because SPF checks do > not match, they actually need to receive the email so they can check > ARC and DKIM headers... During my 19 year career we used software built by Ned Freed. It was perfectly capable of evaluating full content (as well as integrating with 3rd party evaluation software) and return an appropriate SMTP response after DATA. Why is it still so difficult? Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
I have stumbled into the same position as Barry, or maybe a more extreme one. I send no bounce messages, and very few 5xx responses. In my environment, one of the more common causes of non-delivery is a terminated employee. It has not seemed like automated messages sources pay much attention to NDR reports, so sending them seemed like a waste of time. I tried reject during SMTP based on sender verification, but it went badly because of a software bug, and a manager silently lost subscription to a critical service. This leaves me reluctant to try again. I also see clear evidence of spammers trying to do directory harvesting by guessing account names, and I don't want to help them. More generally, there is the need to perform both Sender Authentication and Sender Reputation checking when trying to decide if any particular sender is worthy of a notification. It just became easier to block silently. Doug On Mon, Jul 24, 2023 at 4:10 AM Alessandro Vesely wrote: > On Sun 23/Jul/2023 22:12:55 +0200 Barry Leiba wrote: > >> Without bounces the sender is in the dark. > > > > Yes, if the sender is a human. > > > > Not so, if the sender is a mailing list and that sender will then > > unsubscribe the intended recipient. > > Also not so, if the sender is a malfeasant who may use the bounce > > message for bad purposes. > > > > It's very clear to me that if I think a bounce message will be > > harmful, I will not send one. I will happily prefer silent discard > > over a bounce when I think that's a better approach for that > > situation. Bouncing a legitimate mailing list message is just bad. > > If you have reason to believe you're going to do that... don't. > > Either deliver the message or silently discard it. But don't bounce > > it. > > > Living aside the malfeasant case for a moment, do you think the worthiness > of > bounces can be stated depending on the type of sending? Always? > > The only meaningful signal a mailing list can get out of a 5xx response is > to > deduce that that mailbox doesn't exist any more, so it must be > unsubscribed. > > For alias expansions, there is the case that the author can appreciate to > learn > that her correspondent's mailbox is full, or that her writings was > considered > spam. But again, consider that friends most likely write directly to the > target mailbox, while newsletters deserve the same treatment as mailing > lists. > > Is List-Unsubscribe: an indicator of drop vs. reject? > > > Best > Ale > -- > > > > > > ___ > 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
On Sun 23/Jul/2023 22:12:55 +0200 Barry Leiba wrote: Without bounces the sender is in the dark. Yes, if the sender is a human. Not so, if the sender is a mailing list and that sender will then unsubscribe the intended recipient. Also not so, if the sender is a malfeasant who may use the bounce message for bad purposes. It's very clear to me that if I think a bounce message will be harmful, I will not send one. I will happily prefer silent discard over a bounce when I think that's a better approach for that situation. Bouncing a legitimate mailing list message is just bad. If you have reason to believe you're going to do that... don't. Either deliver the message or silently discard it. But don't bounce it. Living aside the malfeasant case for a moment, do you think the worthiness of bounces can be stated depending on the type of sending? Always? The only meaningful signal a mailing list can get out of a 5xx response is to deduce that that mailbox doesn't exist any more, so it must be unsubscribed. For alias expansions, there is the case that the author can appreciate to learn that her correspondent's mailbox is full, or that her writings was considered spam. But again, consider that friends most likely write directly to the target mailbox, while newsletters deserve the same treatment as mailing lists. Is List-Unsubscribe: an indicator of drop vs. reject? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Yes sir, I’m convinced. Some of my more conservative customers who take security deadly serious won’t even bounce a DMARC failure with a helpful message. It’s discard. I respect the person I’m thinking of who hates bouncing. He’s appropriately paranoid for a InfoSec manager. > On Jul 23, 2023, at 1:13 PM, Barry Leiba wrote: > > >> >> Without bounces the sender is in the dark. > > Yes, if the sender is a human. > > Not so, if the sender is a mailing list and that sender will then > unsubscribe the intended recipient. > Also not so, if the sender is a malfeasant who may use the bounce > message for bad purposes. > > It's very clear to me that if I think a bounce message will be > harmful, I will not send one. I will happily prefer silent discard > over a bounce when I think that's a better approach for that > situation. Bouncing a legitimate mailing list message is just bad. > If you have reason to believe you're going to do that... don't. > Either deliver the message or silently discard it. But don't bounce > it. > > Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> Without bounces the sender is in the dark. Yes, if the sender is a human. Not so, if the sender is a mailing list and that sender will then unsubscribe the intended recipient. Also not so, if the sender is a malfeasant who may use the bounce message for bad purposes. It's very clear to me that if I think a bounce message will be harmful, I will not send one. I will happily prefer silent discard over a bounce when I think that's a better approach for that situation. Bouncing a legitimate mailing list message is just bad. If you have reason to believe you're going to do that... don't. Either deliver the message or silently discard it. But don't bounce it. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> On Jul 7, 2023, at 8:48 AM, John Levine wrote: > > It appears that Barry Leiba said: >> I, too, prefer MUST to SHOULD there, but it was clear to me that we >> will not reach rough consensus on MUST, but that we can reach rough >> consensus on SHOULD. >> >> I do like your suggestion of silent discard rather than bounce, and I >> would want to see that change made -- perhaps with a note that >> aggregate reports will still include information about those discards. > > Silent discard breaks RFC 5321 and some people feel very strongly > about it. For reasons I am sure I don't need to remind you of, don't > go there. > > If you get so many bounces that you find it annoying, that is nature's > way of reminding you that you should do something about it. Personally, > I use sorting rules to put the bounces in a place where they don't > clutter up my main inbox. Without bounces the sender is in the dark. This is a tech ecosystem. Every such community I’ve been involved with in any way has had the “we are all in this together.” I’ve never experienced more generosity than from fellow techies. My second techie job I just hinted I was struggling with something and 15 minutes later he at my office door pointing in the direction of solutions at like 7 pm on a work day. No all nighter needed. He stayed to watch me take his guidance then we called it a day. I help others whenever I possibly can as that’s the ethos engrained in me by mentors such as him. He didn’t just teach me techie stuff. He taught me the ethos. That ethos must continue. We help each other in all kinds of ways including bouncing email to help the admin do the job. We wouldn’t be able to sleep if we made someone’s life harder because of a fuck up. That’s who we are. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> On Jul 6, 2023, at 12:04 PM, Barry Leiba wrote: > > 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. No way. It wouldn’t be possible even if we all made it our life’s work to be standards cops. I agree with stay on target, on scope with pointers as a courtesy when appropriate. I’ve not visited in a while (busy) but I feel the energy is more focused, with people prepared to swap away distractions, time sinks, and wild goose chases. You all are an impressively disciplined group. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri 21/Jul/2023 17:18:50 +0200 Scott Kitterman wrote: On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote: Maybe one day there will be a DMARC with batteries included, where implementers ship default configurations which are effective out of the box. While I don't know how to get there, I think it's counter-productive to exact perfect compliance during the transition. There have to be people who think they have good reasons to push, otherwise we won't move. It's not a transition until there's something to transition to. Currently it's a bridge to nowhere. As Doug said it's not at all clear what everybody's goal in this effort is, I'll state mine too. I run a tiny mail server for family and friends. I find it frustrating to rely on DNSBLs both as a receiver and as a sender, blocking and being blocked at random. I /believe/ there is a better, clean way that anyone could easily operate a small mail server. Email authentication seems to me to be on the path to make that belief come true. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote: >On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote: >> Murray S. Kucherawy wrote on 2023-07-08 02:44: >>> "SHOULD" leaves the implementer with a choice. You really ought to do what >>> it says in the general case, but there might be circumstances where you >>> could deviate from that advice, with some possible effect on >>> interoperability. If you do that, it is expected that you fully understand >>> the possible impact you're about to have on the Internet before proceeding. >>> To that end, we like the use of SHOULD [NOT] to be accompanied by some >>> prose explaining when one might deviate in this manner, such as an example >>> of when it might be okay to do so. >> >> The elaborated Interoperability Considerations in Barry's proposal gives the >> implementer guidance to understand the impact. In my understanding, SHOULD >> is ought to be followed, unless the implementer has good reasons not to. The >> burden of justification is on the implementer, not on the spec. > > >The implementer, in turn, passes the buck to the user. To quote Cisco's email >security appliance[*]: > >The default behavior of the ESA is to never drop any messages unless >explicitly instructed by the customer, so default DMARC verification >profile will have all actions set to “No Action”. > >It has to stay that way until we fix forwarding. > > >>> Does anyone have such an example in mind that could be included here? >>> Specifically: Can we describe a scenario where (a) a sender publishes >>> p=reject (b) with users that post to lists (c) that the community at large >>> would be willing to accept/tolerate? >> >> The scenario I have in mind is a business domain with a high demand for >> protection from exact domain spoofing and a low to no demand for list >> communication. Note the wording in Barry's proposal: "users who *might* post >> messages to mailing lists" (not: "users that post to lists"). > > >ADSP characterized them as domains /with no individual human users/. Yet that >helps only the sender side of the equation. Since human receivers /might/ >want to forward messages to another mailbox, we're back to a protocol with no >humans on either side. A rather disconcerting position. > >Maybe one day there will be a DMARC with batteries included, where >implementers ship default configurations which are effective out of the box. >While I don't know how to get there, I think it's counter-productive to exact >perfect compliance during the transition. There have to be people who think >they have good reasons to push, otherwise we won't move. > It's not a transition until there's something to transition to. Currently it's a bridge to nowhere. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote: Murray S. Kucherawy wrote on 2023-07-08 02:44: "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. The elaborated Interoperability Considerations in Barry's proposal gives the implementer guidance to understand the impact. In my understanding, SHOULD is ought to be followed, unless the implementer has good reasons not to. The burden of justification is on the implementer, not on the spec. The implementer, in turn, passes the buck to the user. To quote Cisco's email security appliance[*]: The default behavior of the ESA is to never drop any messages unless explicitly instructed by the customer, so default DMARC verification profile will have all actions set to “No Action”. It has to stay that way until we fix forwarding. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The scenario I have in mind is a business domain with a high demand for protection from exact domain spoofing and a low to no demand for list communication. Note the wording in Barry's proposal: "users who *might* post messages to mailing lists" (not: "users that post to lists"). ADSP characterized them as domains /with no individual human users/. Yet that helps only the sender side of the equation. Since human receivers /might/ want to forward messages to another mailbox, we're back to a protocol with no humans on either side. A rather disconcerting position. Maybe one day there will be a DMARC with batteries included, where implementers ship default configurations which are effective out of the box. While I don't know how to get there, I think it's counter-productive to exact perfect compliance during the transition. There have to be people who think they have good reasons to push, otherwise we won't move. Best Ale -- [*] https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/215360-best-practice-for-email-authentication.html#toc-hId-103046190 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri, Jul 21, 2023 at 1:22 AM Matthäus Wander wrote: > > "SHOULD" leaves the implementer with a choice. You really ought to do > > what it says in the general case, but there might be circumstances where > > you could deviate from that advice, with some possible effect on > > interoperability. If you do that, it is expected that you fully > > understand the possible impact you're about to have on the Internet > > before proceeding. To that end, we like the use of SHOULD [NOT] to be > > accompanied by some prose explaining when one might deviate in this > > manner, such as an example of when it might be okay to do so. > > The elaborated Interoperability Considerations in Barry's proposal gives > the implementer guidance to understand the impact. In my understanding, > SHOULD is ought to be followed, unless the implementer has good reasons > not to. The burden of justification is on the implementer, not on the spec. > I would agree, but I also think the more information and guidance you put in the hands of the implementer -- especially around something potentially thorny, like this -- the better your document's quality, because the better the outcome will be. > > Does anyone have such an example in mind that could be included here? > > Specifically: Can we describe a scenario where (a) a sender publishes > > p=reject (b) with users that post to lists (c) that the community at > > large would be willing to accept/tolerate? > > The scenario I have in mind is a business domain with a high demand for > protection from exact domain spoofing and a low to no demand for list > communication. Note the wording in Barry's proposal: "users who *might* > post messages to mailing lists" (not: "users that post to lists"). > > I wouldn't include such an example in the RFC, because I don't see a > discussion to this extent for any of the other SHOULD requirements in > the document. > I think you just explained why including such guidance is a good idea. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Murray S. Kucherawy wrote on 2023-07-08 02:44: "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. The elaborated Interoperability Considerations in Barry's proposal gives the implementer guidance to understand the impact. In my understanding, SHOULD is ought to be followed, unless the implementer has good reasons not to. The burden of justification is on the implementer, not on the spec. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The scenario I have in mind is a business domain with a high demand for protection from exact domain spoofing and a low to no demand for list communication. Note the wording in Barry's proposal: "users who *might* post messages to mailing lists" (not: "users that post to lists"). I wouldn't include such an example in the RFC, because I don't see a discussion to this extent for any of the other SHOULD requirements in the document. Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Wed 19/Jul/2023 23:42:55 +0200 Tero Kivinen wrote: Wei Chuang writes: 2) The proposed language calls out "“alumni forwarders”, role-based email aliases, and mailing lists" for consideration by receivers. How should receivers be aware that traffic failing authentication should be reconsidered? Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] call out more strongly the application of those List-id headers? Can something be done so that receivers can identify the other scenarios e.g. role-based email aliases and alumni-forwarders? For alumni forwarders / role-based forwarders things are different, as users who set those up, actually knows who does the forwarding, and they themself recognize that emails coming to those addresses are important to them, and they also trust (university etc) the one doing forwarding. That's particularly true for internal role forwarding. As time goes by, maintenance almost always forget to whitelist forwarders. So if the alumni forwarder / role-based forwarder adds ARC signatures, then the final recipient can whitelist that ARC signer in their setup and say that the policy code that checks the SPF/DKIM/DMARC results can fully trust the signed ARC authentication results from that signer. Setting up an maintaining such trust lists is an effort which requires some planning. And learning about new forwarders who deserve trust is not easily automated too. This of course requires that the recipient SMTP server can't simply reject the incoming email after the MAIL FROM because SPF checks do not match, they actually need to receive the email so they can check ARC and DKIM headers... Shared whitelists may seem to help smoothing this corner. Granting just the minimal trust necessary to receive the message could be afforded at minimal cost. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Wei Chuang writes: > 2) The proposed language calls out "“alumni forwarders”, role-based email > aliases, and mailing lists" for consideration by receivers. How should > receivers be aware that traffic failing authentication should be reconsidered? > Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] > call out more strongly the application of those List-id headers? Can > something be done so that receivers can identify the other scenarios e.g. > role-based email aliases and alumni-forwarders? For alumni forwarders / role-based forwarders things are different, as users who set those up, actually knows who does the forwarding, and they themself recognize that emails coming to those addresses are important to them, and they also trust (university etc) the one doing forwarding. So if the alumni forwarder / role-based forwarder adds ARC signatures, then the final recipient can whitelist that ARC signer in their setup and say that the policy code that checks the SPF/DKIM/DMARC results can fully trust the signed ARC authentication results from that signer. This of course requires that the recipient SMTP server can't simply reject the incoming email after the MAIL FROM because SPF checks do not match, they actually need to receive the email so they can check ARC and DKIM headers... -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
FWIW I think this language is an improvement over the prior language but I would like to point out two concerns: 1) Specifying receivers with "MUST NOT reject" in Section 8.6 "Interoperability Considerations" presumably to to downgrade a p=reject to quarantine with does carry new security risk. I note that "other knowledge and analysis" is not defined and there may be a temptation to blindly do downgrades. I believe the document needs to note that new risk in that Section 5.8 "Policy Enforcement Considerations" [1] and Section 11 "Security considerations" so that receivers apply the downgrade in secure way. Section 5.8 already does note risk for the immediate recipients as says "it may increase the likelihood of accepting abusive mail" however it should note risk in forwarded flows and the risk to those recipients. In particular I'm worried about SPF upgrade attacks as described by Liu et. al. [2]. Here an adversarial senders may exploit overly broad SPF policies of victim domain that permit SPF upgrade as noted Section 4.2.2 in plus relaxed DMARC to enable DMARC From header spoofing. The paper notes that some receivers today may relax DMARC as a user setting to improve deliverability i.e. permit downgrading a p=reject enforcement to p=quarantine in Section 4.2.3 and another setting to forward messages as described in Section 4.3.1. Liu et al. was able to demonstrate sending spoofed state.gov emails that passed DMARC at the receiver despite a "p=reject" policy using those steps as described in Section 5. Presumably receivers that then more broadly apply DMARCbis p=reject downgrade may inadvertently create a new vector for SPF upgrade attacks. Some suggestions are for receivers to be cautioned against doing p=reject downgrades if they don't validate participation by the forwarding recipient. Another is if DMARCbis adopts some scoped authentication, is for domains to deploy a DMARC DKIM-only authentication policy. This not some academic issue and the spammers are very aware of SPF upgrade attack technique i.e. looking for ways to exploit it. We've seen significant scaling of this type of attack over the past two years or so. 2) The proposed language calls out "“alumni forwarders”, role-based email aliases, and mailing lists" for consideration by receivers. How should receivers be aware that traffic failing authentication should be reconsidered? Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] call out more strongly the application of those List-id headers? Can something be done so that receivers can identify the other scenarios e.g. role-based email aliases and alumni-forwarders? [1] DMARCbis: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28 [2] Liu, Enze, et al. "Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy", 8th IEEE European Symposium on Security and Privacy, 2023, https://arxiv.org/abs/2302.07287 -Wei On Thu, Jul 6, 2023 at 7: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
Re: [dmarc-ietf] Another p=reject text proposal
> The issue is not about lists being second class. What lists do to a message > is a privileged function, because > modifying a message can be done maliciously as easily as it can be done > innocently. So the real problem > is that DMARC demoted them from privileged to non-privileged by exposing the > risk inherent in their message > modifications. Non-privileged parricipants do not have permission to modify > messages that they did not author. I do mostly agree with this, and it's a good point. Let me note two things: (1) As I've said before, telling mailing lists how they might deal with this situation is out of scope for THIS DOCUMENT. (2) Telling mailing lists how they might deal with this situation is absolutely in scope for this working group. Apart from rewriting the From header, which you seem to be presenting as the only or best thing that mailing lists can do, there are other solutions that mailing lists could adopt. For example, they could bounce posts from p=reject domains. They could simply not modify messages that are posted from p=reject domains. Ale has a proposal that we will surely discuss at some point that sets up an automated allow-list system so that receiving domains can adjust based on information from the mailing list and the subscriber. We can and should discuss these and consider an update to RFC 7960, perhaps as a BCP for mailing list managers about dealing with DMARC. In this document, specifying the DMARC protocol, we should say how we think DMARC should work. I believe that means we need to say, regardless of who we think will not pay attention, that p=reject is not intended for domains that give out general-use email addresses to general users. But whatever we get consensus to say needs to stay with what the DMARC protocol is and how it's deployed... and then look at the next (BCP) document about the rest. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Thu, Jul 13, 2023 at 6:11 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I did not say "life isn't fair" to be rude, but as a call to acknowledge > the reality that exists rather than the reality you wish you had. > So what I'm hearing, again, is "Lists should get with the times." I'm not ignorant to the fact that the threat model is different than it was in, say, the late 1990s. What I think I have a problem with is how we got to this place, and I'm not sold on the notion that the right, or only, path forward is to just tell them to suck it up. And I don't consider myself a "list advocate". I think I would be a staunch advocate of any use case that got so seriously disrupted by a change imposed unilaterally by one corner of a broad ecosystem. DMARC shipped before it was fully ready, and we're still dealing with the aftermath. As an engineering exercise, its rollout feels to me like either bad design or bad rollout, or both. I get the often attractive nature of "fix forward" as an operational engineering strategy, but it's particularly hard to swallow when the proposed forward paths are all unattractive, and the true source of the problem was questionable to begin with. We know that a large portion of email is unsolicited, unwanted, or > malicious. Consequently, there is no right or certainty of delivery. To > get delivery, you need to satisfy the requirements of the evaluator. > Reality is that lists find this difficulty and do notvwant to do this. > > The issue is not about lists being second class. What lists do to a > message is a privileged function, because modifying a message can be done > maliciously as easily as it can be done innocently. So the real problem > is that DMARC demoted them from privileged to non-privileged by exposing > the risk inherent in their message modifications. Non-privileged > parricipants do not have permission to modify messages that they did not > author. > I think this description is pretty solid, but it presumes that the current situation has always existed. Prior to DMARC, nobody I know thought message modifications made by lists was a privileged function. In fact, I would argue that even if it was, we were fine with lists having that privilege because it served (and still serves) a useful purpose. Parts of the ecosystem, mostly found in MUAs or header field documentation, evolved specifically to make working with lists easier. With DMARC, that privilege was abruptly removed, and then this faction appeared that argued fervently that lists need to snap to. > This IS a plan for compromise. But every part of this solution has been > dismissed in this group because lists are victims that deserve reparations. > I strongly doubt that that's an appropriate analogy. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
I did not say "life isn't fair" to be rude, but as a call to acknowledge the reality that exists rather than the reality you wish you had. We know that a large portion of email is unsolicited, unwanted, or malicious. Consequently, there is no right or certainty of delivery. To get delivery, you need to satisfy the requirements of the evaluator. Reality is that lists find this difficulty and do notvwant to do this. The issue is not about lists being second class. What lists do to a message is a privileged function, because modifying a message can be done maliciously as easily as it can be done innocently. So the real problem is that DMARC demoted them from privileged to non-privileged by exposing the risk inherent in their message modifications. Non-privileged parricipants do not have permission to modify messages that they did not author. So regaining privileged status requires (a) providing one or more alternate authentication system, which will be accepted by some but not all evaluators, (b) developing request, feedback, and diagnostic tools so that the list knows whether privileged stays has been granted by a particular evaluator, and (c) performing conditional From munging based on evaluator requirements. This IS a plan for compromise. But every part of this solution has been dismissed in this group because lists are victims that deserve reparations. Doug Doug On Thu, Jul 13, 2023, 4:20 AM Murray S. Kucherawy wrote: > On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Does anyone believe that things will change if we publish an RFC which >> says "Verizon Media MUST change to p=none"? I don't. >> > > It would be absurd to make such a directed statement. I trust you're > simply being hyperbolic. > > However, a consensus statement by the IETF saying we believe such > operators are using it wrong, or even harmfully, might be meaningful. In > hindsight I wish we had made RFC 7489 more forceful on this point. > > Lists have been hurt by the move to authenticated email. Point taken. >> However, the world is not going back to the good old days,. >> > > I infer from this that not only do you believe a revert is out of the > question, but so too is compromise going forward. I suggest that's rather > an extreme position to take. > > There is no hope for a list solution to appear from outside the list >> community. >> > > I don't agree. If the problem originated outside the list community, > maybe the solution ought to come from there. > > If or when list advocates reconcile themselves to that reality, we can >> start making real headway on solving the problem. >> > > In my view, this is in effect the same thing as saying "Life isn't fair" > again. > > >> The outlines of the solution have been on the table for several years >> already. But those solutions have been ignored because list advocates are >> waiting for everyone else to change to meet list needs. >> > > Can you please explain why lists are so clearly second class use cases to > you? > > -MSK, participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Thu 13/Jul/2023 10:20:00 +0200 Murray S. Kucherawy wrote: On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster wrote: Does anyone believe that things will change if we publish an RFC which says "Verizon Media MUST change to p=none"? I don't. It would be absurd to make such a directed statement. I trust you're simply being hyperbolic. Hyperbole is easily removed by s/VerizonMedia/domains which [conditions]/ as Scott put it[*]. However, a consensus statement by the IETF saying we believe such operators are using it wrong, or even harmfully, might be meaningful. In hindsight I wish we had made RFC 7489 more forceful on this point. Maybe a MUST at the time would have changed something. Maybe not. In any case, we have to move forward from where we are _now_. The value of saying MUST NOT now doesn't seem to achieve much. It sounds something in between sordid revenge and the "MUST (BUT WE KNOW YOU WON'T)" 2119 extension of RFC 6919... Lists have been hurt by the move to authenticated email. Point taken. However, the world is not going back to the good old days,. I infer from this that not only do you believe a revert is out of the question, but so too is compromise going forward. I suggest that's rather an extreme position to take. To put it more mildly, one could say that lists /suffered/ authentication. They didn't use it to authenticate posters, for example. There is no hope for a list solution to appear from outside the list community. I don't agree. If the problem originated outside the list community, maybe the solution ought to come from there. Agreed. Still, lists have to accept it, wherever it comes from. If or when list advocates reconcile themselves to that reality, we can start making real headway on solving the problem. List /advocates/, not list developers, implementers, general users... In my view, this is in effect the same thing as saying "Life isn't fair" again. The outlines of the solution have been on the table for several years already. But those solutions have been ignored because list advocates are waiting for everyone else to change to meet list needs. I disagree on this point. Yes, John's analysis[†] is of 2014, nearly a decade, albeit ARC was added in 2016. It seems to be obvious that there is no /simple/ solution. Yet, we didn't explore the more complicated ones. Can you please explain why lists are so clearly second class use cases to you? 2nd class was sanctioned by Yahoo's and AOL's move in 2014. I heard they explicitly said so, but cannot find a pointer. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/yaNersE40EtsM2KojlMa_3El3Ys [†] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Does anyone believe that things will change if we publish an RFC which > says "Verizon Media MUST change to p=none"? I don't. > It would be absurd to make such a directed statement. I trust you're simply being hyperbolic. However, a consensus statement by the IETF saying we believe such operators are using it wrong, or even harmfully, might be meaningful. In hindsight I wish we had made RFC 7489 more forceful on this point. Lists have been hurt by the move to authenticated email. Point taken. > However, the world is not going back to the good old days,. > I infer from this that not only do you believe a revert is out of the question, but so too is compromise going forward. I suggest that's rather an extreme position to take. There is no hope for a list solution to appear from outside the list > community. > I don't agree. If the problem originated outside the list community, maybe the solution ought to come from there. If or when list advocates reconcile themselves to that reality, we can > start making real headway on solving the problem. > In my view, this is in effect the same thing as saying "Life isn't fair" again. > The outlines of the solution have been on the table for several years > already. But those solutions have been ignored because list advocates are > waiting for everyone else to change to meet list needs. > Can you please explain why lists are so clearly second class use cases to you? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Does anyone believe that things will change if we publish an RFC which says "Verizon Media MUST change to p=none"? I don't. Lists have been hurt by the move to authenticated email. Point taken. However, the world is not going back to the good old days,. There is no hope for a list solution to appear from outside the list community. If or when list advocates reconcile themselves to that reality, we can start making real headway on solving the problem. The outlines of the solution have been on the table for several years already. But those solutions have been ignored because list advocates are waiting for everyone else to change to meet list needs. DF On Wed, Jul 12, 2023, 3:30 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hi, > > Le 08/07/2023 à 20:24, Scott Kitterman a écrit : > > > > You can equally argue that these receivers are merely following the > policy advice provided by the sending domain (it has reject right in the > name) and this problem is entirely generated by sender's inappropriate use > of p=reject. > > > > I don't think engineering the location where the blame lands is the > right place to focus. I've done plenty of blame avoidance engineering in > my day, but I don't think it's what the IETF should be doing. > > This is not about blame avoidance. Blame avoidance is what happens right > now on this very list, with author domains and mail receivers first > blaming each other, then colluding to accuse absentee forwarders… > > This is about avoiding the Tragedy of Commons where everyone waits for > the breakage to somehow solve itself (or, more cynically, for the victim > to resignate). The standard can help by clearly stating who has to act > in which circumstances. A MUST is better than a SHOULD, an it might well > be that two SHOULDs are worse than just one. > > Cheers, > Baptiste > > ___ > 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
Hi, Le 07/07/2023 à 23:58, John R Levine a écrit : > > Why is it up to the recipient systems (the ones that do not care) to > make life easier for lists? Mailing list packages already do lots of > analysis of bounce messages. How about if they fix their bounce > processing to recognize DMARC failures and do something different. Why? Because it's brittle and will only bring them more headaches? At the very least, DMARC would need to use its own 5xy reply code to avoid the need for parsing the reply text… Or simply because they are *not* DMARC participants, and thus have no reason to read this list? Standards usually serve to organize interoperability between participants, not to inflict demands upon unrelated third parties that they knowingly break. That being said, maybe there is some simpler and better advice we can give to mailing list operators who happen to listen: "If messages bounce, first try to forcibly set the digest sending mode for this user. If digests bounce too, then it's not DMARC, unsubscribe as usual". If the mailing list software has a digest mode, implementation is straightforward, and I can see no downsides compared to unsubscribe right from the start. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Hi, Le 08/07/2023 à 20:24, Scott Kitterman a écrit : > > You can equally argue that these receivers are merely following the policy > advice provided by the sending domain (it has reject right in the name) and > this problem is entirely generated by sender's inappropriate use of p=reject. > > I don't think engineering the location where the blame lands is the right > place to focus. I've done plenty of blame avoidance engineering in my day, > but I don't think it's what the IETF should be doing. This is not about blame avoidance. Blame avoidance is what happens right now on this very list, with author domains and mail receivers first blaming each other, then colluding to accuse absentee forwarders… This is about avoiding the Tragedy of Commons where everyone waits for the breakage to somehow solve itself (or, more cynically, for the victim to resignate). The standard can help by clearly stating who has to act in which circumstances. A MUST is better than a SHOULD, an it might well be that two SHOULDs are worse than just one. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Hi, Le 07/07/2023 à 21:09, Scott Kitterman a écrit : > Doesn't sieve happen during delivery, after the message has been accepted? > Is so, I don't think it's a useful comparison to make. > > The lack of bounce/rejection messages results in messages that vanish and > undermines the reliability of the email ecosystem. I agree that silent > discard between MTAs is bad and we should not encourage it. Please remember that "silent discard" is already proposed as a delivery option in today's DMARCBis, section 8.3 (I wouldn't have dared to use those words otherwise, I have principles too :-) ). But if it makes people feel better, we can call it "delivery to user-inaccessible system quarantine". We can even add that messages are not to be deleted from said quarantine until the DMARC reports have been sent, so that no message ever just "vanishes". Rejecting at SMTP time also constrains the additional analysis that we say Mail Receiver MUST do before rejecting, so deferred discard is bound to become more common with DMARCBis anyway. Also, maybe time has come to be pragmatic, as DMARC has been causing breakage for 10 years already, all RFCs not withstanding. Bounces are feedback sent to the wrong place, and bring no useful consequences. At best they are ignored (which is just as sinful as not sending them), and in the common worst case, they are misunderstood and break havoc. Feedback to the right place (the author domain) happens through DMARC reports. On the benefit side, suppressing the risk of bounces avoids forcing the mailing list operators to second-guess mail receivers and apply problematic workarounds a priori. Recipients whose mail operator correctly applies additional analysis can thus enjoy an unaltered experience, which provides incentive. And recipients who lose messages because their operator discards them can always elect to receive digests, which are not impacted by DMARC. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
It's actually not even enough to check when you subscribe, though that will help keep the user from being surprised later. But you also have to check every time a message is posted to the list, because anyone's domain could have changed to p=reject recently. And anyway, yes, the IETF considered that and decided, as you say, to try to be more inclusive. But we've seen problems caused by the From rewriting also, related to difficulties in replying... it's not benign. Barry On Tue, Jul 11, 2023 at 4:30 PM Tero Kivinen wrote: > > Barry Leiba writes: > > > 2) As others have observed, the mailing list problem is > > > exclusively an evaluator error. An evaluator's job is to allow > > > safe and wanted messages while blocking unsafe or unwanted > > > messages. > > > > I disagree. As I and others have observed, those creating the problem > > are the ones who are using p=reject in a way that it was not intended > > to be used. > > If we simply want to "fix" the mailing list issue, the mailing lists > could simply refuse any subscription attempt from address which > publishes p=reject, and say that your email address is not compatible > with mailing lists in general, use some other address when sending > emails to mailing list. > > On the other hand mailing list adminstrators usually try to include > everybody, and not block people if they can cope with them, and thats > why they do From address rewriting etc instead of just rejecting > subscription requests. > -- > kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Barry Leiba writes: > > 2) As others have observed, the mailing list problem is > > exclusively an evaluator error. An evaluator's job is to allow > > safe and wanted messages while blocking unsafe or unwanted > > messages. > > I disagree. As I and others have observed, those creating the problem > are the ones who are using p=reject in a way that it was not intended > to be used. If we simply want to "fix" the mailing list issue, the mailing lists could simply refuse any subscription attempt from address which publishes p=reject, and say that your email address is not compatible with mailing lists in general, use some other address when sending emails to mailing list. On the other hand mailing list adminstrators usually try to include everybody, and not block people if they can cope with them, and thats why they do From address rewriting etc instead of just rejecting subscription requests. -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> To Murray's observation about fairness, my thoughts: I don't see any use of the word "fair" in the message from Murray that you quote. > 1) Life is not fair. This is impolitely dismissive. Please don't do that. > 2) As others have observed, the mailing list problem is exclusively an > evaluator error. An evaluator's job > is to allow safe and wanted messages while blocking unsafe or unwanted > messages. I disagree. As I and others have observed, those creating the problem are the ones who are using p=reject in a way that it was not intended to be used. Many who support that use say that it's necessary to use it that way; I and others disagree with that, and we can have and are having that discussion. But that *is* the genesis of the problem. It's not fundamentally a mailing list problem and it's not really an evaluator problem (but I'm willing to look at it partially that way, because evaluators do have a choice, within DMARC, about how to use the information that DMARC provides). > 3) The problem can be solved by senders not asserting reject, by lists > rewriting From, or by evaluators > using more than DMARC Fail alone. Our document should address all three. > The only one that is > guaranteed to provide delivery under all sender-evaluator combinations will > be From rewrite. I don't think DMARCbis should be addressing what mailing lists can do to work around it, and I disagree with your last sentence there: rewriting the "From" header field has many problems and fails in a number of ways, making it *not* guaranteed to provide delivery. It's also violating the sense of what "From" and "Sender" fields are meant to convey. As many of us have said, it's an ugly hack and is not something that should be in a Standards Track specification. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
To Murray's observation about fairness, my thoughts: 1) Life is not fair. 2) As others have observed, the mailing list problem is exclusively an evaluator error. An evaluator's job is to allow safe and wanted messages while blocking unsafe or unwanted messages. 3) The problem can be solved by senders not asserting reject, by lists rewriting From, or by evaluators using more than DMARC Fail alone. Our document should address all three. The only one that is guaranteed to provide delivery under all sender-evaluator combinations will be From rewrite. Doug Foster On Sun, Jul 9, 2023, 1:14 AM Murray S. Kucherawy wrote: > On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Malicious impersonation creates a need for authentication. If the list >> makes changes that disable the originator's authentication, then it is the >> list's problem to find a way to convince the recipient that the message is >> not a malicious impersonation. ARC and Munging together are the best >> available way to do so, because no other options are on the table. >> > > I continue to disagree with this line of thinking. Lists have been > behaving a particular way, with important operational benefits to users > (unrelated to authentication), for a very long time. That they should > suddenly be told by senders that the Internet works a different way > starting now and those behaviors are wrong and must be fixed, to me, defies > reason. > > If you want to blame someone for the list problem, blame the criminals. >> > > Here, we agree. > > -MSK, participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Mon 10/Jul/2023 17:50:54 +0200 John Levine wrote: FYI, the IETF's mail relay for role accounts like WG chairs breaks DKIM signatures. It's a bug, but it took quite a while to realize what the problem was, since some signatures get through OK. It's an old python library helpfully tidying up the message headers. Fixing the bug is nontrivial due to the cruftiness of the surrounding code. See tools-discuss for way more details. In theory relays shouldn't break DKIM, in practice ... Let me note, tangentially, that that may also look like a DKIM over-signing issue. My tool[*] didn't verify the original signatures of the message I'm replying to because Content-Type: was changed to «text/plain; charset="utf-8"», where it likely was «text/plain; charset="us-ascii"». We can consider the bug to be in the helpfully tidying up, in the over-signing practice, or somewhere in between. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/wFTm0dfCdWso5c7uJz4Or8XBoZU/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> Another consideration is that a non-standard, internal blocking would have > been > effective only for their users. Perhaps they though they were doing the rest > of the world a favor by following standard protocols. Had that MUST NOT been > in place then, /perhaps/ we'd have spared ourselves lots of fuss and p=reject > would have remained a seldom deployed feature. To be clear, I don't think "seldom deployed" is right: I think there's a lot of valid and intended use for p=reject... just not for a global mailbox provider and domains like it. > +1, when we'll learn to use ARC we can stop From: munging. Will we then > retract that MUST NOT (and DMARCbis with it)? The intent, and I think it's hinted at in the text I proposed, is that when things get to where these interoperability issues are adequately mitigated and the requirements put forth in the Interoperability Consideration section should change, we would publish an RFC that "updates" this one and specifies the new requirements (or rescinds them entirely) as appropriate. Barry ___ 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: >> Is “generally” true here? I think I have seen exceptions to DKIM signatures >> being valid on relayed >> messages, although I can’t dig up any examples right now. > >You seem to be answering the question you're asking. I know of none >of these relays that break DKIM signatures, but we hear that some do. FYI, the IETF's mail relay for role accounts like WG chairs breaks DKIM signatures. It's a bug, but it took quite a while to realize what the problem was, since some signatures get through OK. It's an old python library helpfully tidying up the message headers. Fixing the bug is nontrivial due to the cruftiness of the surrounding code. See tools-discuss for way more details. In theory relays shouldn't break DKIM, in practice ... R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Sat 08/Jul/2023 20:13:44 +0200 John Levine wrote: It appears that Richard Clayton said: They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. We get that, but why did they have to inflict DMARC policy on the world rather than just adjusting their own mail software to filter out incoming mail with Yahoo return addresses from other places? I assume the answer was that the DMARC code was already written so it was cheaper. Another consideration is that a non-standard, internal blocking would have been effective only for their users. Perhaps they though they were doing the rest of the world a favor by following standard protocols. Had that MUST NOT been in place then, /perhaps/ we'd have spared ourselves lots of fuss and p=reject would have remained a seldom deployed feature. strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. There seem to be a fair number of people working on ARC who disagree. +1, when we'll learn to use ARC we can stop From: munging. Will we then retract that MUST NOT (and DMARCbis with it)? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> I’m one of those people who prefer for “xxx considerations” sections to be a
> descriptive discussion
> of the xxx issues and not contain new normative requirements.
I disagree, and certainly the Security Considerations sections are
normative and often use BCP 14 key words.
> the statement above sounds a little like the normative language is moving
> because it only addresses
> an interoperability issue.
It's moving in order to (1) put the requirements for senders and
recipients in one place in order to make the reasoning clear and (2)
to allow a broader discussion of the issues and the reasons without
cluttering the sections that lay out the protocol. I think it's
important to put the requirements and the reasons for those
requirements in the same place: its clearer to readers and it
emphasizes the needs for the requirements.
> [Is there a significance to the indentation of the 3rd, 6th, and 8th
> paragraphs below?]
It calls out the requirements clearly. The rest of the text explains
why, and the indented text contains the requirements concisely.
> >not an address authorized for the sending domain. DKIM signatures
> >will generally remain valid in these relay situations.
>
> Is “generally” true here? I think I have seen exceptions to DKIM signatures
> being valid on relayed
> messages, although I can’t dig up any examples right now.
You seem to be answering the question you're asking. I know of none
of these relays that break DKIM signatures, but we hear that some do.
So, "generally" means it's not wrong. I'm happy to use a different
word or phrase if you suggest one.
> > 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.
>
> A few paragraphs earlier discussed “alumni” and role-based addresses. But now
> it sounds like only
> mailing lists are important. It would seem that domains that send messages to
> alumni and role-based
> addresses also SHOULD NOT publish p=reject. But there’s no way for those
> domains to know when
> they’re sending to such addresses.
The relaying for alumni and roles will ("generally", as noted)
maintain DKIM authentication, which mitigates the issue for those
types, and we already put the MUST requirement of not using SPF alone
with p=reject. So this requirement need only be for mailing lists, as
they're the cases that (again, generally) break DKIM signatures.
> I agree with Murray’s comment: a SHOULD NOT like this need to cite what the
> exceptions are.
> “Our domain is very worried about domain spoofing” and the like don’t seem
> like a suitable
> exceptions to me.
I think the explanatory text makes the situation abundantly clear,
without the need for further clarification here. As I've said, I
prefer MUST NOT here, but it's clear to me that we will not get rough
consensus on that, and SHOULD NOT will still cover the situation
reasonably. And, like it or not, "we're worried about spoofing" *will
be* the reason this is ignored. Do you (or Murray) really want to say
that explicitly? I certainly don't.
> > It is therefore critical that receiving domains MUST NOT reject
> > incoming messages solely on the basis of a p=reject policy by
> > the sending domain. Receiving domains must use the DMARC
> > policy as part of their disposition decision, along with other
> > knowledge and analysis.
>
> Isn’t this basically just factoring address alignment along with DKIM and SPF
> pass into spam filters?
> I’m pretty sure spamassassin already does that, even without DMARC.
Not just that, no. Receiving domains might consider various
allow-lists, contents of recipients' address books, message content
filtering, knowledge of common mailing list managers, and other such
factors.
Barry
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Murray S. Kucherawy writes: > On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > Consequently, the problem remains: How does an evaluator distinguish > between a legitimate list and a malicious attack? > > If we had a reliable answer to that, this would've been over ages ago. > Unfortunately, any mechanism we create for lists to distinguish their traffic > can be trivially co-opted by bad actors. I think phishing attacks using mailing list format would not be as efficient as it would be to inpersonate some other user that the intended recipient is familiar with. Mailing list are also something that quite a lot people already have special filters for, i.e., direct them to separate mailbox, allow them to go through without spam checking etc. For mailing lists users actually joined willingly, the users are familiar to, and have ability to cope. If it is mailing list they got added without their real consent, then if some of those messages gets lost because it is run through spam filtering and they get some extra spam points because no dkim signature etc the user probably do not care even if they are thrown away. The problem with DMARC checking is that it is usually done too early, and without consulting intended recipient whitelist/policy etc. Users can't add rules that say that mailing lists having DKIM signature of header.d=ietf.org are ok, and should get through even when the DMARC checks fails. -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
The point isn't to place blame. The point is to specify how to maintain interoperability, and in the case of DMARC p-reject there are two places where we can lessen the interop problems: telling the senders not to use p=reject in inappropriate conditions, and telling the receivers to consider the interop issues when honoring the p=reject policy. The latter is necessary partly because some senders will ignore the former... but it is also necessary because even in cases where p=reject *is* used as it was intended, some legitimate mail will get caught up by it and judgment is important. None of this text is meant to chastise or blame. Barry On Sat, Jul 8, 2023 at 2:25 PM Scott Kitterman wrote: > > > > On July 8, 2023 6:16:46 PM UTC, Tero Kivinen wrote: > >Brotman, Alex writes: > >> 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. > > > >If receivers ignore that, then at least we can complain to them and > >say that you should not do that, as the RFC says you should use other > >information too if they want to get important forwarded emails > >through. For example we in iki.fi have been regularly been helping > >people with their broken spf etc records which break forwarding, and > >several times we have actually managed to explain the situation and > >they have change their settings. Quite often those people simply > >follow whatever some consultant etc suggested, and they did not > >understood at all that they at the same time broke other things. > > > >Quite often they do want to reduce the amoung of support calls, and if > >they get support calls every time some forwarded email from mailing > >list or from forwarding gets rejected, they most likely will notice > >that and fix their setup. > > > >> 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. > > > >There is no good way for forwards to mungle message in such way that > >return path/DKIM/user expectations stays intact. I myself for example > >find the From address mangling done by this mailing list really > >annoying as I need to use extra time to parse the =40 addresses to > >find out domain name of the sender. > > > >For mailing list this is just annoying but you can do that, but for > >regular forwarding you can't do that as you want to keep the DKIM > >signature intact. > > > >And this problem is not generated by forwarders, it is generated by > >the receivers who only use DMARC and no other information while > >rejecting emails. So there is no point of asking forwarders to fix > >things that was broken by DMARC... > > You can equally argue that these receivers are merely following the policy > advice provided by the sending domain (it has reject right in the name) and > this problem is entirely generated by sender's inappropriate use of p=reject. > > I don't think engineering the location where the blame lands is the right > place to focus. I've done plenty of blame avoidance engineering in my day, > but I don't think it's what the IETF should be doing. > > Scott K > > ___ > 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
Our solution approach is binary: either we fix the list problem by doing less authentication, which is Barry's proposal, or we fix the list problem by doing alternate authentication.Alternate authentication is the one we need to pursue, because the other approach has already been rejected by too many participants. List traffic needs to be evaluated based on the list's own reputation. The MailFrom address cannot accomplish this result on its own. From munging provides the necessary trigger to ensure that all evaluators will use the list domain reputation. There is upward and backward compatible with all evaluators. The secondary but largely independent problem is the user experience caused by From munging. Until recently, we had no solution to this. We also had the related objection that From munging fixes DMARC by deception. ARC addresses both of these issues. ARC provides the information needed to reverse the munging, which means that evaluators can solve the user experience problem. ARC also provides data so that the forwarding event is well documented, so there is no deception. >From munging does mean that the list takes full responsibility for the message, and consequently the list takes the reputation hit if unwanted traffic is forwarded. Some posts have suggested that lists think they can presently dodge that risk somehow. I say they bear that risk already. Ideally, all forwarding should be pre-approved. The forwarder needs to know that the traffic is wanted and will be accepted. So we need more than From munging and ARC-derived un-munging. But this combination is a start. Doug On Sun, Jul 9, 2023, 12:27 AM Murray S. Kucherawy wrote: > On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Consequently, the problem remains: How does an evaluator distinguish >> between a legitimate list and a malicious attack? >> > > If we had a reliable answer to that, this would've been over ages ago. > Unfortunately, any mechanism we create for lists to distinguish their > traffic can be trivially co-opted by bad actors. > > >> My answer: Lists need to use From munging to avoid DMARC FAIL, and hope >> that sophisticated evaluators will use ARC data to un-mung before delivery. >> > > Someone else asserted that lists have been dealing with DMARC damage by, > among other things, rewriting From fields for some years now. Let me pose > a couple of questions to list operators and developers and those friendly > to those audiences: > > 1) Are list operators and developers tolerating this situation, > temporarily, because they think this crew is going to come up with a less > disruptive permanent solution to which they expect to migrate one day? > > 2) If not, have they resigned themselves to such things as From rewriting > as the way of the future? > > 3) If so, how big (or small) is the set of DMARC accommodations on which > they seem to be converging? > > -MSK, participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Malicious impersonation creates a need for authentication. If the list > makes changes that disable the originator's authentication, then it is the > list's problem to find a way to convince the recipient that the message is > not a malicious impersonation. ARC and Munging together are the best > available way to do so, because no other options are on the table. > I continue to disagree with this line of thinking. Lists have been behaving a particular way, with important operational benefits to users (unrelated to authentication), for a very long time. That they should suddenly be told by senders that the Internet works a different way starting now and those behaviors are wrong and must be fixed, to me, defies reason. If you want to blame someone for the list problem, blame the criminals. > Here, we agree. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Consequently, the problem remains: How does an evaluator distinguish > between a legitimate list and a malicious attack? > If we had a reliable answer to that, this would've been over ages ago. Unfortunately, any mechanism we create for lists to distinguish their traffic can be trivially co-opted by bad actors. > My answer: Lists need to use From munging to avoid DMARC FAIL, and hope > that sophisticated evaluators will use ARC data to un-mung before delivery. > Someone else asserted that lists have been dealing with DMARC damage by, among other things, rewriting From fields for some years now. Let me pose a couple of questions to list operators and developers and those friendly to those audiences: 1) Are list operators and developers tolerating this situation, temporarily, because they think this crew is going to come up with a less disruptive permanent solution to which they expect to migrate one day? 2) If not, have they resigned themselves to such things as From rewriting as the way of the future? 3) If so, how big (or small) is the set of DMARC accommodations on which they seem to be converging? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Scott Kitterman writes: > You can equally argue that these receivers are merely following the > policy advice provided by the sending domain (it has reject right in > the name) and this problem is entirely generated by sender's > inappropriate use of p=reject. True, thats why the proposed text also says you SHOULD NOT put p=reject... :-) > I don't think engineering the location where the blame lands is the > right place to focus. I've done plenty of blame avoidance > engineering in my day, but I don't think it's what the IETF should > be doing. It would be much better when people would really remember that having valid or not valid DMARC/DKIM/SPF for email does not tell anything whether the email is bad/spam/unwanted. Regardless whether the DMARC/DKIM/SPF is valid you always need to use other methods to filter emails, so as you need to do that anyways while receiving emails, there is no problems of using same things also for p=reject messages. You can use the failed dmarc with p=reject as one of the inputs to feed your actual email filtering system, the dmarc p=reject SHOULD NOT BE your only email filtering system. -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On July 8, 2023 6:16:46 PM UTC, Tero Kivinen wrote: >Brotman, Alex writes: >> 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. > >If receivers ignore that, then at least we can complain to them and >say that you should not do that, as the RFC says you should use other >information too if they want to get important forwarded emails >through. For example we in iki.fi have been regularly been helping >people with their broken spf etc records which break forwarding, and >several times we have actually managed to explain the situation and >they have change their settings. Quite often those people simply >follow whatever some consultant etc suggested, and they did not >understood at all that they at the same time broke other things. > >Quite often they do want to reduce the amoung of support calls, and if >they get support calls every time some forwarded email from mailing >list or from forwarding gets rejected, they most likely will notice >that and fix their setup. > >> 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. > >There is no good way for forwards to mungle message in such way that >return path/DKIM/user expectations stays intact. I myself for example >find the From address mangling done by this mailing list really >annoying as I need to use extra time to parse the =40 addresses to >find out domain name of the sender. > >For mailing list this is just annoying but you can do that, but for >regular forwarding you can't do that as you want to keep the DKIM >signature intact. > >And this problem is not generated by forwarders, it is generated by >the receivers who only use DMARC and no other information while >rejecting emails. So there is no point of asking forwarders to fix >things that was broken by DMARC... You can equally argue that these receivers are merely following the policy advice provided by the sending domain (it has reject right in the name) and this problem is entirely generated by sender's inappropriate use of p=reject. I don't think engineering the location where the blame lands is the right place to focus. I've done plenty of blame avoidance engineering in my day, but I don't think it's what the IETF should be doing. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Brotman, Alex writes: > 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. If receivers ignore that, then at least we can complain to them and say that you should not do that, as the RFC says you should use other information too if they want to get important forwarded emails through. For example we in iki.fi have been regularly been helping people with their broken spf etc records which break forwarding, and several times we have actually managed to explain the situation and they have change their settings. Quite often those people simply follow whatever some consultant etc suggested, and they did not understood at all that they at the same time broke other things. Quite often they do want to reduce the amoung of support calls, and if they get support calls every time some forwarded email from mailing list or from forwarding gets rejected, they most likely will notice that and fix their setup. > 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. There is no good way for forwards to mungle message in such way that return path/DKIM/user expectations stays intact. I myself for example find the From address mangling done by this mailing list really annoying as I need to use extra time to parse the =40 addresses to find out domain name of the sender. For mailing list this is just annoying but you can do that, but for regular forwarding you can't do that as you want to keep the DKIM signature intact. And this problem is not generated by forwarders, it is generated by the receivers who only use DMARC and no other information while rejecting emails. So there is no point of asking forwarders to fix things that was broken by DMARC... -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
It appears that Richard Clayton said: >They then moved on to just using random identities from the same domain >as the recipient. This led a great many Yahoo users to believe that a >great many other Yahoo users had been compromised, leading to a >significant loss of faith in the integrity of the platform. We get that, but why did they have to inflict DMARC policy on the world rather than just adjusting their own mail software to filter out incoming mail with Yahoo return addresses from other places? I assume the answer was that the DMARC code was already written so it was cheaper. >strong, mailing lists (and other forwarders that mangle email) have been >coping with p=reject for nearly a decade -- so that trying >(ineffectually in practice) to make their lives easier at this point is >a snare and a delusion. There seem to be a fair number of people working on ARC who disagree. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
*Note: The following is a general rule of thumb for me.* From my functional specification protocol language coding standpoint: MUST --> NO OPTION. Technically enabled with no switch to disable. SHOULD -> OPTIONAL, Default is ON, enabled MAY --> OPTIONAL, Default is ON or OFF depending on implementation With the special RFC documentation format designed/written for a very wide audience from managers, system admins, coders, engineers, etc, it offers semantics with lower and upper case guidelines. sometimes purposely ambiguous (to keep it open ended) and in the IETF RFC, we have used the UPPER CASE language as a way to create code especially with standard track items. Those who choose to ignore the UPPER CASE interop advice often risk having the proverbial book thrown at them. With lower case semantics, this has been my overall implementation methods: may, should --> may be implemented as options as with upper case must --> may be implemented and enabled with hidden option to disable. -- HLS On 7/8/2023 12:49 PM, Richard Clayton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message, Murray S. Kucherawy writes Some of my IETF mentors (ahem) taught me some stuff about the use of SHOULD [NOT] that have stuck with me, and I'm going to pressure test this against that advice.� Let's see how this goes.� :-) "SHOULD" leaves the implementer with a choice.� You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. I noted that one of the earlier messages which endorsed MUST NOT said that of course some people might know better -- which is what I always understood SHOULD NOT was for ! � If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding.� To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. not so much "OK" as "necessary". Yahoo's original statement (I'm prepared to name names rather than pussyfoot around this) on the deployment of p=reject is discussed here: https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/ and I believe it is widely understood that it was particularly deployed to counter the "address book spammers" of the time. These bad guys originally persuaded people to open their email by forging it to appear to come from their friends (having compromised relevant address books). They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. Does anyone have such an example in mind that could be included here?� Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? So the example you seek might be phrased along the lines of when failing to set p=reject means that significant quantities of forged email will be delivered and this will cause damage. Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Murray S. Kucherawy writes >Some of my IETF mentors (ahem) taught me some stuff about the use >of SHOULD [NOT] that have stuck with me, and I'm going to pressure >test this against that advice. Let's see how this goes. :-) > >"SHOULD" leaves the implementer with a choice. You really ought to >do what it says in the general case, but there might be >circumstances where you could deviate from that advice, with some >possible effect on interoperability. I noted that one of the earlier messages which endorsed MUST NOT said that of course some people might know better -- which is what I always understood SHOULD NOT was for ! > If you do that, it is >expected that you fully understand the possible impact you're about >to have on the Internet before proceeding. To that end, we like >the use of SHOULD [NOT] to be accompanied by some prose explaining >when one might deviate in this manner, such as an example of when >it might be okay to do so. not so much "OK" as "necessary". Yahoo's original statement (I'm prepared to name names rather than pussyfoot around this) on the deployment of p=reject is discussed here: https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/ and I believe it is widely understood that it was particularly deployed to counter the "address book spammers" of the time. These bad guys originally persuaded people to open their email by forging it to appear to come from their friends (having compromised relevant address books). They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. >Does anyone have such an example in mind that could be included >here? Specifically: Can we describe a scenario where (a) a sender >publishes p=reject (b) with users that post to lists (c) that the >community at large would be willing to accept/tolerate? So the example you seek might be phrased along the lines of when failing to set p=reject means that significant quantities of forged email will be delivered and this will cause damage. Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZKmTft2nQQHFxEViEQJ4zACfUiVCRzGjK68phKi73kl0kg0CKnAAnjAB ft3PPkV73wIPjvYs7tCjrCsm =EUgy -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Sat 08/Jul/2023 02:44:19 +0200 Murray S. Kucherawy wrote: On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote: 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. Some of my IETF mentors (ahem) taught me some stuff about the use of SHOULD [NOT] that have stuck with me, and I'm going to pressure test this against that advice. Let's see how this goes. :-) "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The preceding, non-indented paragraph seems to devise a tolerance boundary in the future: 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. /More/ mature and /better/ resolved might still be obscure. For the time being, IME, the ecosystem is mature enough to resolve the mailing list interoperability issues by From: munging. I agree it might become more mature and find out better ways. Yet, the current level might seem enough to permit p=reject where it is necessary —unless there are situations (unknown to me) where the damage is still serious or substantial. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Start with the underlying objective: Evaluators SHOULD accept mailing list traffic. Google's requirement: Given whatever standards-track DMARCbis rules we produce, these rules MUST be something that can be fully automated. Consequently, the problem remains: How does an evaluator distinguish between a legitimate list and a malicious attack? My answer: Lists need to use From munging to avoid DMARC FAIL, and hope that sophisticated evaluators will use ARC data to un-mung before delivery. This seems like a complete solution, and the only one which does not ask evaluators to weaken their security defenses. DF On Fri, Jul 7, 2023, 8:44 PM Murray S. Kucherawy wrote: > Still no hat on. > > I can see the compromise in language that's been proposed here, and I > appreciate the effort by the chairs. > > Two things I'd like to raise. First: > > On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba > wrote: > >> 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. >> > > Some of my IETF mentors (ahem) taught me some stuff about the use of > SHOULD [NOT] that have stuck with me, and I'm going to pressure test this > against that advice. Let's see how this goes. :-) > > "SHOULD" leaves the implementer with a choice. You really ought to do > what it says in the general case, but there might be circumstances where > you could deviate from that advice, with some possible effect on > interoperability. If you do that, it is expected that you fully understand > the possible impact you're about to have on the Internet before > proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied > by some prose explaining when one might deviate in this manner, such as an > example of when it might be okay to do so. > > Does anyone have such an example in mind that could be included here? > Specifically: Can we describe a scenario where (a) a sender publishes > p=reject (b) with users that post to lists (c) that the community at large > would be willing to accept/tolerate? > > The second thing is that the level of disruption we saw on the IETF lists > when "p=reject" was rolled out prematurely suggests to me that > "interoperability issues" by itself is a bit more euphemistic than is > deserved. Can we add in a word like "serious" or "substantial"? > > -MSK > ___ > 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
Still no hat on. I can see the compromise in language that's been proposed here, and I appreciate the effort by the chairs. Two things I'd like to raise. First: On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote: > 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. > Some of my IETF mentors (ahem) taught me some stuff about the use of SHOULD [NOT] that have stuck with me, and I'm going to pressure test this against that advice. Let's see how this goes. :-) "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The second thing is that the level of disruption we saw on the IETF lists when "p=reject" was rolled out prematurely suggests to me that "interoperability issues" by itself is a bit more euphemistic than is deserved. Can we add in a word like "serious" or "substantial"? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
I do like your suggestion of silent discard rather than bounce, and I would want to see that change made -- perhaps with a note that aggregate reports will still include information about those discards. Having thought about it for a minute, I have a better question. We already know that sites that reject list mail for DMARC failures do not care about mailing lists because if they did care, they wouldn't do that. So I think the chances of them making a change that only benfits lists rounds to zero. Why is it up to the recipient systems (the ones that do not care) to make life easier for lists? Mailing list packages already do lots of analysis of bounce messages. How about if they fix their bounce processing to recognize DMARC failures and do something different. Certainly for the large recipepent systems that handle the bulk of mail these days the rejection messages allcontain words like DMARC or authentication so it's not hard to figure out. Bonus question: if you send a lot of mail to a recipient system that it rejects, you will get a bad reputation and they are likely to view the mail you send with great scepticism, even for the stuff that survives DMARC. Suppressing the bounce messages only makes it harder to figure out why the mail is all disappearing. Extra bonus question: how many minutes will it take for spammers to hope that suppressing the bounces will somehow help them evade filters (whether or not that's true) so they'll start putting List-ID on plain old spam? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS: some of us actaully do want the bounces from our lists, since we have various hacks to evade DMARC and want to know if they don't work. We find this proposal has negative benefit. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Doesn't sieve happen during delivery, after the message has been accepted? Is so, I don't think it's a useful comparison to make. The lack of bounce/rejection messages results in messages that vanish and undermines the reliability of the email ecosystem. I agree that silent discard between MTAs is bad and we should not encourage it. Scott K On July 7, 2023 7:02:58 PM UTC, Barry Leiba wrote: >It's not a question of the bounces being annoying: it's a question of >the bounces harming mailing list operation by causing unsubscribes. >Given the choice of "breaking 5321" (which I don't buy, as Sieve >already has a silent discard option, for example) and "breaking normal >mailing list operation", I'll take the former to prevent the latter >every time. > >Barry > >On Fri, Jul 7, 2023 at 11:48 AM John Levine wrote: >> >> It appears that Barry Leiba said: >> >I, too, prefer MUST to SHOULD there, but it was clear to me that we >> >will not reach rough consensus on MUST, but that we can reach rough >> >consensus on SHOULD. >> > >> >I do like your suggestion of silent discard rather than bounce, and I >> >would want to see that change made -- perhaps with a note that >> >aggregate reports will still include information about those discards. >> >> Silent discard breaks RFC 5321 and some people feel very strongly >> about it. For reasons I am sure I don't need to remind you of, don't >> go there. >> >> If you get so many bounces that you find it annoying, that is nature's >> way of reminding you that you should do something about it. Personally, >> I use sorting rules to put the bounces in a place where they don't >> clutter up my main inbox. >> >> 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
Re: [dmarc-ietf] Another p=reject text proposal
It's not a question of the bounces being annoying: it's a question of the bounces harming mailing list operation by causing unsubscribes. Given the choice of "breaking 5321" (which I don't buy, as Sieve already has a silent discard option, for example) and "breaking normal mailing list operation", I'll take the former to prevent the latter every time. Barry On Fri, Jul 7, 2023 at 11:48 AM John Levine wrote: > > It appears that Barry Leiba said: > >I, too, prefer MUST to SHOULD there, but it was clear to me that we > >will not reach rough consensus on MUST, but that we can reach rough > >consensus on SHOULD. > > > >I do like your suggestion of silent discard rather than bounce, and I > >would want to see that change made -- perhaps with a note that > >aggregate reports will still include information about those discards. > > Silent discard breaks RFC 5321 and some people feel very strongly > about it. For reasons I am sure I don't need to remind you of, don't > go there. > > If you get so many bounces that you find it annoying, that is nature's > way of reminding you that you should do something about it. Personally, > I use sorting rules to put the bounces in a place where they don't > clutter up my main inbox. > > R's, > John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Barry, I did a quick review and comparison for changes. Overall, it appears this document is more clear in key specific areas but also more complex. At this point, DMARCbis is about Local Policy, System Administrative choices and suggested guidelines, codified and/or new. As such, I don’t think this document is a "Standard Track" material with its many ambiguous considerations and changes. Consider the following: Is this document backward compatible with existing DMARC1 behavior? If not, what are the key protocol changes implementers need to consider for updating DMARC1 to DMARCbis? Can this be summarized? Thanks — HLS > On Jul 7, 2023, at 9:17 AM, Barry Leiba wrote: > > I, too, prefer MUST to SHOULD there, but it was clear to me that we > will not reach rough consensus on MUST, but that we can reach rough > consensus on SHOULD. > > I do like your suggestion of silent discard rather than bounce, and I > would want to see that change made -- perhaps with a note that > aggregate reports will still include information about those discards. > > Barry > > On Fri, Jul 7, 2023 at 9:03 AM Baptiste Carvello > wrote: >> >> Hi, >> >> I consider this a step backwards. The MUST requirement on the author >> domain finally made it clear, after a lost decade, *who* is responsible >> for solving the breakage of indirect mailflows. Problem solving starts >> with acknowledging one's responsibilities. >> >> This proposal goes back to a muddy shared responsibility between the >> author domain and the mail receiver. This is the best way to make sure >> nothing changes, as each waits for the other to act. Mailing lists can >> expect to suffer for more long years. No wonder the From-munging >> proponents are rejoicing! >> >> If this goes in, at least something has to be done to reduce bounces, >> such as: >> >> — Section 8.3 — >> >> ADD >> The Mail Receiver MUST reject with "silent discard" when rejecting >> messages with a List-Id header. >> END >> >> That way, each party's choices will mostly impact their own messages. >> Mailing list operators can then take a step back, undo any ugly >> workarounds, and let DMARC participants decide between themselves, on a >> case by case basis, how they solve *their* deliverability problems. >> >> Cheers, >> Baptiste >> >> Le 06/07/2023 à 16:55, Barry Leiba a écrit : >>> 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 >> >> >> ___ >> 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] Another p=reject text proposal
It appears that Barry Leiba said: >I, too, prefer MUST to SHOULD there, but it was clear to me that we >will not reach rough consensus on MUST, but that we can reach rough >consensus on SHOULD. > >I do like your suggestion of silent discard rather than bounce, and I >would want to see that change made -- perhaps with a note that >aggregate reports will still include information about those discards. Silent discard breaks RFC 5321 and some people feel very strongly about it. For reasons I am sure I don't need to remind you of, don't go there. If you get so many bounces that you find it annoying, that is nature's way of reminding you that you should do something about it. Personally, I use sorting rules to put the bounces in a place where they don't clutter up my main inbox. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
I, too, prefer MUST to SHOULD there, but it was clear to me that we will not reach rough consensus on MUST, but that we can reach rough consensus on SHOULD. I do like your suggestion of silent discard rather than bounce, and I would want to see that change made -- perhaps with a note that aggregate reports will still include information about those discards. Barry On Fri, Jul 7, 2023 at 9:03 AM Baptiste Carvello wrote: > > Hi, > > I consider this a step backwards. The MUST requirement on the author > domain finally made it clear, after a lost decade, *who* is responsible > for solving the breakage of indirect mailflows. Problem solving starts > with acknowledging one's responsibilities. > > This proposal goes back to a muddy shared responsibility between the > author domain and the mail receiver. This is the best way to make sure > nothing changes, as each waits for the other to act. Mailing lists can > expect to suffer for more long years. No wonder the From-munging > proponents are rejoicing! > > If this goes in, at least something has to be done to reduce bounces, > such as: > > — Section 8.3 — > > ADD > The Mail Receiver MUST reject with "silent discard" when rejecting > messages with a List-Id header. > END > > That way, each party's choices will mostly impact their own messages. > Mailing list operators can then take a step back, undo any ugly > workarounds, and let DMARC participants decide between themselves, on a > case by case basis, how they solve *their* deliverability problems. > > Cheers, > Baptiste > > Le 06/07/2023 à 16:55, Barry Leiba a écrit : > > 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 > > > ___ > 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
Baptiste, Your comments assume uniform agreement that mailing lists have no role in the problem or it's solution. I do not agree. Malicious impersonation creates a need for authentication. If the list makes changes that disable the originator's authentication, then it is the list's problem to find a way to convince the recipient that the message is not a malicious impersonation. ARC and Munging together are the best available way to do so, because no other options are on the table. If you want to blame someone for the list problem, blame the criminals. Silent discard is only part of the solution. Any server that consistently sends rejected messages should expect to be blacklisted, first by the recipient organization and then by the RBLs. To prevent block escalation, the list must find a way to authenticate. DF On Fri, Jul 7, 2023, 9:03 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hi, > > I consider this a step backwards. The MUST requirement on the author > domain finally made it clear, after a lost decade, *who* is responsible > for solving the breakage of indirect mailflows. Problem solving starts > with acknowledging one's responsibilities. > > This proposal goes back to a muddy shared responsibility between the > author domain and the mail receiver. This is the best way to make sure > nothing changes, as each waits for the other to act. Mailing lists can > expect to suffer for more long years. No wonder the From-munging > proponents are rejoicing! > > If this goes in, at least something has to be done to reduce bounces, > such as: > > — Section 8.3 — > > ADD > The Mail Receiver MUST reject with "silent discard" when rejecting > messages with a List-Id header. > END > > That way, each party's choices will mostly impact their own messages. > Mailing list operators can then take a step back, undo any ugly > workarounds, and let DMARC participants decide between themselves, on a > case by case basis, how they solve *their* deliverability problems. > > Cheers, > Baptiste > > Le 06/07/2023 à 16:55, Barry Leiba a écrit : > > 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 > > > ___ > 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
Hi, I consider this a step backwards. The MUST requirement on the author domain finally made it clear, after a lost decade, *who* is responsible for solving the breakage of indirect mailflows. Problem solving starts with acknowledging one's responsibilities. This proposal goes back to a muddy shared responsibility between the author domain and the mail receiver. This is the best way to make sure nothing changes, as each waits for the other to act. Mailing lists can expect to suffer for more long years. No wonder the From-munging proponents are rejoicing! If this goes in, at least something has to be done to reduce bounces, such as: — Section 8.3 — ADD The Mail Receiver MUST reject with "silent discard" when rejecting messages with a List-Id header. END That way, each party's choices will mostly impact their own messages. Mailing list operators can then take a step back, undo any ugly workarounds, and let DMARC participants decide between themselves, on a case by case basis, how they solve *their* deliverability problems. Cheers, Baptiste Le 06/07/2023 à 16:55, Barry Leiba a écrit : > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Barry, in my previous note, I used MTA generically, but was particularly thinking of forwarders. I assume that senders and their outbound filtering services will be smart enough to not undermine their own signatures. I have tried unsuccessfully to accept your assertion that a forwarder is not a participant in DMARC, or John's related assertion that forwarders need no advice. There are many small hosting services that become forwarders as a side effect of a client choice, and do not have the same level of understanding as a mailing list admin who has been through the DMARC-AOL wars.These admins and their software vendors need guidance, as confirmed by a conversation that I had just last week with an admin who was having forwarded messages blocked. Legitimate forwarders have two objectives: 1. To have their forwarded messages accepted by the ultimate recipient, and 2. To avoid forwarding messages that are harmful to the ultimate recipient. To accomplish these goals, a forwarder SHOULD be aware of DMARC, and SHOULD use it to block malicious impersonations. If the forwarder makes changes that render signatures unverifiable, it SHOULD undertake other efforts, such as ARC and From Munging, to prevent wanted messages from being blocked incorrectly. These objectives cannot be achieved if the forwarder is uninformed or if the forwarder claims to be a non-participant in DMARC. Doug Foster On Thu, Jul 6, 2023 at 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
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 chec
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 ad
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] 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
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
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] 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
[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
