Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
On Thu, Jun 17, 2021 at 9:18 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > This is frustrating. NP is a new design and the design issues should > have been discussed before we got to this point. I don't know why so many > people are eager to not define the new technology. > Please don't conflate "I still don't understand what you're talking about" with "I am eager not to define NP" or "I am unwilling to acknowledge (something)". They're not the same thing, and only the former is true. Your message continues to assert something abstract. I'll repeat my previous request: Could you craft a sample message (including DKIM details), sample envelope, and sample DNS context (including A, , MX, and SPF details) that highlights the problem you're talking about? Maybe then it'll snap into focus. NP is an effort to partition the RFC 7489 SP=NONE result set, so that a > subset of all SP results can be blocked on some additional criteria. > This additional criterion could be based on non-existent as indicated by > NXDOMAIN, or it could be based on "not used for email" based on a criterion > to be defined. Either approach needs to have a mechanism for > non-compliant names to be made compliant. I believe that this should > involve a DNS entry, but the compliance measure should be specific to the > NP test. Requiring that every FROM address be linked to an IP address > does not meet that requirement. > If I squint at this, maybe I can see what you're trying to argue: " example.com" can't publish an "np" policy if they use a subdomain of " example.com" that has no representation of any kind in the DNS. Is that correct? If so, do you find this to be a defect, or simply a limitation to be documented? If you think it's a defect, why is that so? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
Yes, The test should most certainly define how MX="." and SPF="-ALL" affect the test. This is why I said that the test needs a more complete definition, but many were unwilling to even address that part of the problem. Even with those modifications, the test is only applicable for names that are also used for SMTP MAILFROM. This does not cover all names that are used for FROM. I infer that the A/ component is included in the test definition because these might indicate an implicit MX. The use of implicit MX is unnecessary, and I suspect unlikely to be in use by DMARC-publishing domains.It would a minor compliance step to require domain owners to replace implicit MX with explicit MX, so that the test will accurately indicate names that are used for SMTP purposes. Doug Foster On Thu, Jun 17, 2021 at 7:13 AM Alessandro Vesely wrote: > On Wed 16/Jun/2021 20:02:21 +0200 John Levine wrote: > > Let's close ticket #112 and stop. > > > I agree that the definition given in the PSD is clear enough: > > For DMARC purposes, a non-existent domain is a domain for which there > is an NXDOMAIN or NODATA response for A, , and MX records. This > is a broader definition than that in [RFC8020]. > > However, by that definition a domain with a Null MX [RFC7505] is an > existent > domain for DMARC purposes. Perhaps this apparent contradiction could be > noted > by adding a sentence somewhere, for example: > > Even though the bare existence of a domain does not entail that it can > send > or receive email, the presence or absence of the relevant DNS RRs > determines > which policy between sp= and np= is applicable. If a DMARC record is > found > for a domain that would be non-existent by the above definition, the p= > policy defined there is still the one to be applied. > > Would that add clarity? > > > 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] Ticket #11 (and #112) - Proposed language
This is frustrating. NP is a new design and the design issues should have been discussed before we got to this point. I don't know why so many people are eager to not define the new technology. There seems to be an unwillingness to acknowledge the current state of the email ecosystem. There seems to be a mythology that any email suffix used with a mailing service must also exist elsewhere in the ecosystem as an SMTP sender and receiver. The MX/A//.SPF seems to be based on this myth. There is no such necessity in the real world. For a legitimate message, where a mailing service uses its own identity for MailFrom and the client's identity for the From, the From address has very few constraints: - IETF format rules - DMARC policy if present - Mailing service business practices On mailing service business practices: I find that the major mailing services can be trusted to correctly present the client organization. But that does not include a requirement that the email suffix has a separate identity as an SMTP sender and receiver. My data indicates that they will be happy to let @Example.Com send a message from @EasterSale.Marketing.Example.com. On DMARC policy NP is only relevant if: - The message does not authenticate. DMARC PASS continues to be a final result. - A domain P policy does not apply. P policies override SP and NP policies. - The SP policy is NONE and the NP policy is QUARANTINE or REJECT. (If the NP policy is the same as the SP policy, the result will be equivalent to RFC7489 SP without NP. If the NP policy is weaker than the SP policy, the configuration is simply stupid.) NP is an effort to partition the RFC 7489 SP=NONE result set, so that a subset of all SP results can be blocked on some additional criteria. This additional criterion could be based on non-existent as indicated by NXDOMAIN, or it could be based on "not used for email" based on a criterion to be defined. Either approach needs to have a mechanism for non-compliant names to be made compliant. I believe that this should involve a DNS entry, but the compliance measure should be specific to the NP test. Requiring that every FROM address be linked to an IP address does not meet that requirement. Doug Foster Doug Foster On Thu, Jun 17, 2021 at 3:57 AM Murray S. Kucherawy wrote: > I continue to not understand the defect you're highlighting here. > > I think you've expressed yourself primarily in the abstract. Could you > craft a sample message, sample envelope, and sample DNS context that > highlights the problem you're talking about? Maybe then it'll snap into > focus. > > On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> NXDomain on RFC5322.From is a completely different issue.It means >> that the name is only used for service provider messaging, and is therefore >> not linked to any IP address or other physical infrastructure. It affects >> the ability to define a meaningful NP test. The issue becomes irrelevant >> to DMARC if and only if we drop the NP policy idea completely. >> >> The proposed MX/A//SPF test has two significant problems: >> - It incorrectly classifies some names as NP because they do not need >> MX/A//SPF records because they are not tied to an IP address, and we >> have provided a very poor mechanism for a domain owner to come into >> compliance. >> > > There's a workaround here: If I want to use a name that is not represented > in the DNS according to that test, all I need to do is DKIM sign with my > parent domain. That makes "p" apply because now you have an aligned > "pass", which presumably trumps any "np" that's set. > > If you aren't signing with DKIM in that scenario, and you obviously can't > pass SPF either, then you can't possibly hope to pass DMARC irrespective of > any test being done on the name's validity. > > - It incorrectly classifies some names that are not used for email as not >> NP, simply because they have an A/ record. It provides no method for >> the domain owner to signal that the name is not used for email and >> therefore should be treated as NP. >> > > If they're not used for email, then they're not in DMARC's problem space. > > At any rate, since PSD has been approved, I'm hoping the experiment is > underway, or will be soon, and then we might have some actual data about > the severity of this defect and thus also possibly some hints about ways it > can be mitigated. > > -MSK > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
However, by that definition a domain with a Null MX [RFC7505] is an existent domain for DMARC purposes. True, but so what? If you want to do a DMARC alignment check, you do it the same way as for any other domain. For the umpteenth time, DMARC is not the magic anti-spam bullet, and you continue to use whatever other filtering methods you use. Would that add clarity? No. Let's close #112 and talk about something else. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
On Wed 16/Jun/2021 20:02:21 +0200 John Levine wrote: Let's close ticket #112 and stop. I agree that the definition given in the PSD is clear enough: For DMARC purposes, a non-existent domain is a domain for which there is an NXDOMAIN or NODATA response for A, , and MX records. This is a broader definition than that in [RFC8020]. However, by that definition a domain with a Null MX [RFC7505] is an existent domain for DMARC purposes. Perhaps this apparent contradiction could be noted by adding a sentence somewhere, for example: Even though the bare existence of a domain does not entail that it can send or receive email, the presence or absence of the relevant DNS RRs determines which policy between sp= and np= is applicable. If a DMARC record is found for a domain that would be non-existent by the above definition, the p= policy defined there is still the one to be applied. Would that add clarity? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
I continue to not understand the defect you're highlighting here. I think you've expressed yourself primarily in the abstract. Could you craft a sample message, sample envelope, and sample DNS context that highlights the problem you're talking about? Maybe then it'll snap into focus. On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > NXDomain on RFC5322.From is a completely different issue.It means that > the name is only used for service provider messaging, and is therefore not > linked to any IP address or other physical infrastructure. It affects the > ability to define a meaningful NP test. The issue becomes irrelevant to > DMARC if and only if we drop the NP policy idea completely. > > The proposed MX/A//SPF test has two significant problems: > - It incorrectly classifies some names as NP because they do not need > MX/A//SPF records because they are not tied to an IP address, and we > have provided a very poor mechanism for a domain owner to come into > compliance. > There's a workaround here: If I want to use a name that is not represented in the DNS according to that test, all I need to do is DKIM sign with my parent domain. That makes "p" apply because now you have an aligned "pass", which presumably trumps any "np" that's set. If you aren't signing with DKIM in that scenario, and you obviously can't pass SPF either, then you can't possibly hope to pass DMARC irrespective of any test being done on the name's validity. - It incorrectly classifies some names that are not used for email as not > NP, simply because they have an A/ record. It provides no method for > the domain owner to signal that the name is not used for email and > therefore should be treated as NP. > If they're not used for email, then they're not in DMARC's problem space. At any rate, since PSD has been approved, I'm hoping the experiment is underway, or will be soon, and then we might have some actual data about the severity of this defect and thus also possibly some hints about ways it can be mitigated. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
You or the others seem to be confusing NXDOMAIN on RFC5321.MailFrom lookup with NXDOMAIN on RFC5322.FROM. The issues are very different. NXDomain on the MailFrom lookup says neither the SPF policy nor the SMTP domain exist, and therefore there is no reverse path. Rejecting such messages makes a lot of sense and, as has been said, has nothing to do with DMARC. NXDomain on RFC5322.From is a completely different issue.It means that the name is only used for service provider messaging, and is therefore not linked to any IP address or other physical infrastructure. It affects the ability to define a meaningful NP test. The issue becomes irrelevant to DMARC if and only if we drop the NP policy idea completely. The proposed MX/A//SPF test has two significant problems: - It incorrectly classifies some names as NP because they do not need MX/A//SPF records because they are not tied to an IP address, and we have provided a very poor mechanism for a domain owner to come into compliance. - It incorrectly classifies some names that are not used for email as not NP, simply because they have an A/ record. It provides no method for the domain owner to signal that the name is not used for email and therefore should be treated as NP. With the expectation of significant errors in both directions, we do not have a usable definition of NP. Doug Foster On Wed, Jun 16, 2021 at 1:51 PM Alessandro Vesely wrote: > On Wed 16/Jun/2021 18:01:08 +0200 John Levine wrote: > > It appears that Alessandro Vesely said: > >>However, to reject based just on NXDOMAIN is too harsh. > > > > I dunno, in my experience it's quite common, and if you do, the chances > of losing a message you care > > about are negligible. > > > It's been customary to reject NXDOMAIN in smtp.mailfrom since when I > recall it. > To reject NXDOMAIN in header.from is (was) an ADSP feature which doesn't > seem > to be very widespread. DMARC dropped it a long time ago. > > > > In any event, this has nothing to do with DMARC. If for some reason you > want to do a DMARC evaluation > > of a non-existent domain, you can use the organizational domain or I > suppose PSD. > > > It might make sense to reject that ~30% which doesn't even have an > organizational domain (dubbed totally astray in my previous post). But I > still > receive From: on a mailing list. > Rejecting that > risks getting unsubscribed. Perhaps mailing lists deserve a special > permission... > > > 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] Ticket #11 (and #112) - Proposed language
+1 Ken. From: dmarc on behalf of John Levine Sent: Wednesday, 16 June 2021, 19:02 To: dmarc@ietf.org Cc: ves...@tana.it Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language It appears that Alessandro Vesely said: >It might make sense to reject that ~30% which doesn't even have an >organizational domain (dubbed totally astray in my previous post). But I still >receive From: on a mailing list. Rejecting that >risks getting unsubscribed. Perhaps mailing lists deserve a special >permission... Or perhaps mailing lists should refrain from forwarding messages from cowards who use fake addresses and don't sign their mail. Either way, I still don't see what this has to do with DMARC. Let's close ticket #112 and stop. 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] Ticket #11 (and #112) - Proposed language
On Wed, Jun 16, 2021 at 2:02 PM John Levine wrote: > It appears that Alessandro Vesely said: > >It might make sense to reject that ~30% which doesn't even have an > >organizational domain (dubbed totally astray in my previous post). But I > still > >receive From: on a mailing list. > Rejecting that > >risks getting unsubscribed. Perhaps mailing lists deserve a special > permission... > > Or perhaps mailing lists should refrain from forwarding messages from > cowards who > use fake addresses and don't sign their mail. > > Either way, I still don't see what this has to do with DMARC. Let's close > ticket #112 and stop. > > R's, > John > +1 Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
It appears that Alessandro Vesely said: >It might make sense to reject that ~30% which doesn't even have an >organizational domain (dubbed totally astray in my previous post). But I >still >receive From: on a mailing list. Rejecting >that >risks getting unsubscribed. Perhaps mailing lists deserve a special >permission... Or perhaps mailing lists should refrain from forwarding messages from cowards who use fake addresses and don't sign their mail. Either way, I still don't see what this has to do with DMARC. Let's close ticket #112 and stop. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
On Wed 16/Jun/2021 18:01:08 +0200 John Levine wrote: It appears that Alessandro Vesely said: However, to reject based just on NXDOMAIN is too harsh. I dunno, in my experience it's quite common, and if you do, the chances of losing a message you care about are negligible. It's been customary to reject NXDOMAIN in smtp.mailfrom since when I recall it. To reject NXDOMAIN in header.from is (was) an ADSP feature which doesn't seem to be very widespread. DMARC dropped it a long time ago. In any event, this has nothing to do with DMARC. If for some reason you want to do a DMARC evaluation of a non-existent domain, you can use the organizational domain or I suppose PSD. It might make sense to reject that ~30% which doesn't even have an organizational domain (dubbed totally astray in my previous post). But I still receive From: on a mailing list. Rejecting that risks getting unsubscribed. Perhaps mailing lists deserve a special permission... Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
It appears that Alessandro Vesely said: >However, to reject based just on NXDOMAIN is too harsh. I dunno, in my experience it's quite common, and if you do, the chances of losing a message you care about are negligible. In any event, this has nothing to do with DMARC. If for some reason you want to do a DMARC evaluation of a non-existent domain, you can use the organizational domain or I suppose PSD. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
On Tue 15/Jun/2021 01:19:03 +0200 Douglas Foster wrote: It took me only one day to find examples of this;,non-existent subdomains used on legitimate messages sent by mailing services. The FROM suffix correctly reflects the parent organization, but the full email suffix does not appear in DNS. Me too. I reviewed my logs for 2021 and got this: 88 NXDOMAIN found out of 160,473 messages: 35 bounces (empty mailfrom), 26 not found host in an existing suffix, 27 totally astray. Except for bounces, which just reflect a poorly configured server, I wouldn't swear to their legitimacy. For the few samples of which I still have the score, it was high. However, to reject based just on NXDOMAIN is too harsh. This situation means that we cannot distinguish between valid and invalid email suffixes using DNS alone, we must require domain owner signalling. I'd agree, but the idea of suggesting to signal such lack of registration over the DNS is to diabolically persist on an error. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
Thank you for asking. OK., I will use the term "email suffix" for the part of an email address that follows the @ character, and "DNS domain" for a name that appears in DNS as a domain object. An email suffix can legitimately be associated with an A/ resource record that is not a DNS domain. For example, an alarm monitoring system might send alarms using the server's host name as the email suffix (e.g. ala...@monitore.xample.com). MX and SPF can also be configured for Monitor.Example.Com even though it is not a DNS domain. This is specifically authorized by RFC 5321. A spoofed email address could use any email suffix, such as nots...@trickedyou.example.com. Our interest must extend beyond names that are in DNS. In my mailstream, most messages sent from mailing services use the mailing service domain for the SMTP address. This insures that the message produces SPF PASS. It also means that the FROM domain name has no necessary dependence on any DNS entry. It took me only one day to find examples of this;,non-existent subdomains used on legitimate messages sent by mailing services. The FROM suffix correctly reflects the parent organization, but the full email suffix does not appear in DNS. This situation means that we cannot distinguish between valid and invalid email suffixes using DNS alone, we must require domain owner signalling. How does a domain owner signal that @bounce.e.example.com is valid as a FROM domain, even though the name is only used for mailing service messages?Under the current draft, the domain owner must associate the name with an IP address using an MX, A, or SPF record, even though the name has no legitimate connection to the chosen IP address. I do not consider this acceptable. In the real world, I fear that implementing such a requirement will have unexpected consequences, and network administrators who share my fear will be reluctant to comply with our draft. I focused on SP and NP because it is the SP or NP policy which provides inheritance, Inheritance has to be the primary way that we defend against abuse of unused and non-existent email suffixes You asked a lot of questions. I think I should stop there and give you a chance to respond before going further. Doug Foster On Mon, Jun 14, 2021 at 7:12 AM Alessandro Vesely wrote: > Doug, > > maybe it's me, but I have problems understanding your proposal. Let me > quote > what seems to hamper my comprehension. > > Besides, #11 in the Subject: is obviously a typo. > > > On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote: > > ties the design directly to the mailing list problem. > > > I couldn't see where mailing lists are taken into account. > > > >However,this authentication can be lost in transit if message > modification > > occurs in transit, as discussed in RFC 7960. This possibility can make > domain > > owners reluctant to move beyond sp=none. > > > Why do you consider SP irrespective of P? Actually, SP could be used by > "simple" mail sites, those which make no use of subdomains for email. In > such > cases, setting sp=reject can safely prevent generic abuses even for > domains > having p=none. It sounds similar to null SPF records for non-mail hosts. > > > > x.1 Implement mail domains as DNS domains with domain-level DMARC > policies. > > > > Mail domains are often implemented as DNS domains, but this is not > required. > > > Please, stick to well established jargon. Tim made a good synthesis in > section > 2.2 and ensuing ones. A /DNS domain/ is defined by RFC 1034: > > A domain is identified by a domain name, and consists of that part of > the domain name space that is at or below the domain name which > specifies the domain. > > In this sense, the concept of non-existing domain names that are > legitimately > used sounds like a contradiction in terms. > > > > Once all used mail domain names are configured as DNS domains, they can > be > > configured with DMARC policies. > > AFAICS, a /used mail domain name/ which is not a DNS name is a > /non-existent > domain/ found in some (forged) email addresses. I agree that such > practice > should be discouraged. Yet, that doesn't seem to be the point here... > > BTW, are there organizations that use non-existent (sub) domains during > the > delivery of legitimate messages? Years ago I saw sporadic mailing list > authors > forged like john@nospamexample.com. Is that what you're talking > about? > > > > - For mail domain names that are not used with SMTP, a new TXT record is > > defined, with content "DMARCFROMv1". The presence of this TXT record > > indicates that the associated DNS domain, named DNS resource record, or > > wildcard DNS record should be considered as potentially in use as an > > RFC5322.From domain name. > > > Ok, that is clear, but, IMHO, won't work. Working MXes or IP addresses > are a > necessary condition to receive mail. Thus, a purist receiver has to > accept > such domains as
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
Doug, maybe it's me, but I have problems understanding your proposal. Let me quote what seems to hamper my comprehension. Besides, #11 in the Subject: is obviously a typo. On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote: ties the design directly to the mailing list problem. I couldn't see where mailing lists are taken into account. However,this authentication can be lost in transit if message modification occurs in transit, as discussed in RFC 7960. This possibility can make domain owners reluctant to move beyond sp=none. Why do you consider SP irrespective of P? Actually, SP could be used by "simple" mail sites, those which make no use of subdomains for email. In such cases, setting sp=reject can safely prevent generic abuses even for domains having p=none. It sounds similar to null SPF records for non-mail hosts. x.1 Implement mail domains as DNS domains with domain-level DMARC policies. Mail domains are often implemented as DNS domains, but this is not required. Please, stick to well established jargon. Tim made a good synthesis in section 2.2 and ensuing ones. A /DNS domain/ is defined by RFC 1034: A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. In this sense, the concept of non-existing domain names that are legitimately used sounds like a contradiction in terms. Once all used mail domain names are configured as DNS domains, they can be configured with DMARC policies. AFAICS, a /used mail domain name/ which is not a DNS name is a /non-existent domain/ found in some (forged) email addresses. I agree that such practice should be discouraged. Yet, that doesn't seem to be the point here... BTW, are there organizations that use non-existent (sub) domains during the delivery of legitimate messages? Years ago I saw sporadic mailing list authors forged like john@nospamexample.com. Is that what you're talking about? - For mail domain names that are not used with SMTP, a new TXT record is defined, with content "DMARCFROMv1". The presence of this TXT record indicates that the associated DNS domain, named DNS resource record, or wildcard DNS record should be considered as potentially in use as an RFC5322.From domain name. Ok, that is clear, but, IMHO, won't work. Working MXes or IP addresses are a necessary condition to receive mail. Thus, a purist receiver has to accept such domains as valid. Therefore traditionalist domain operators will not see a compelling need to define any auxiliary TXT records. A new RR type of this kind would most probably be going to characterize mass mailers who hasten to adopt any new trick that seems to offer a chance to increase deliverability. Undoubtedly, someone would be tempted to discard senders based on that (as it happened to DKIM...) An organization which wants to say sp=reject but does use some email subdomains had better define plain DMARC records for them. Records can be easily duplicated by CNAMEs. If we needed to vary some parts but not others, for example a different policy but the same aggregate reporting address, we should define something equivalent to SPF's include. - For used domain names that are not in DNS at all, a DMARCFROMv1 TXT record is needed to indicate that the name is used for mail. Actually, /any/ record definition will turn a domain into an existing one. However, by Section 2.7 of PSD, which defines the MX/A/ test, such domain would still be non-existing. In that sense, DMARCFROMv1 conflicts with PSD. x,3 Implement SPF -ALL policies on unused names. Organizations that have configured SPF to protect their valid RFC5321.MailFrom domains may not have taken the extra measure of using SPF to obstruct names that are not used for mail. While not directly part of DMARC, an authentication result of "DMARC=NONE SPF=FAIL" is a more meaningful result than "DMARC=NONE, SPF=NONE". Consequently, it is desirable to ensure SPF=FAIL for any names that are never used as RFC5321.MailFrom domain names. Since SPF has no inheritance, this requires many entries. That's a well known SPF issue: http://www.open-spf.org/FAQ/Common_mistakes/#all-domains There used to circulate scripts to generate null SPF records. It would help if DNS hosting services implemented a checkbox to carry out such task. But this if far OT. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
On Sat, Jun 12, 2021 at 8:56 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Below is my proposed language for dealing with the problems that NP is > intended to address: > - unused DNS names > - non-existent DNS names > > It provides supporting rationale, and provides a more complete solution > than anything suggested previously, and ties the design directly to the > mailing list problem. > > I have labelled the sections starting with "X," because I am not sure of > the best way to position this text into the flow of the current draft. > > Doug Foster > > x. Reducing the scope of the SP policy > > DMARC introduces a method for the domain owner to state "at time of > transmission, authorized emails will always authenticate using DMARC > criteria". > The portion of the above statement is an incorrect assertion and is meaningless to validators and mailbox receivers. It is well known (at least to validators and receivers) that there is a significant subset of senders who publish incorrect SPF records or improperly DKIM sign messages or improperly publish DKIM in DNS or improperly publish DMARC in DNS. Further, a validator or mailbox provider can only go by what they see and know at the time they attempt to determine whether a given message validates or not. > However,this authentication can be lost in transit if message modification > occurs in transit, as discussed in RFC 7960. This possibility can make > domain owners reluctant to move beyond sp=none. This is a significant > loss, because sp=none opens a vast namespace to domain abuse, including > - names that are DNS domains but are not protected by a domain-level DMARC > policy > - names that are DNS records records rather than DNS names, and cannot be > protected by a domain-level DMARC policy > - names that are not in DNS at all, and therefore cannot be protected by a > domain-level DMARC policy. > Senders may be reluctant to implement DMARC for any number of reasons. I've given email authentication training to thousands of people through OTA when it was around and to/through the U.S. Federal government. Not once has anyone raised the above as reasons for reluctance to implement DMARC, either in total or for implementing policy. > > To mitigate these impacts, it is useful to distinguish names used as email > domains from names that are not used for email. Names that are never used > for email are never authorized at time of transmission, and therefore can > be blocked without concern about in-transit modifications. Several > methods are presented for addressing this objective. > As pointed out above, you are asserting impacts not in evidence when you state that these impacts are of concern. A difference, in order to be a difference, must make a difference. You have presented nothing to show that this is an issue causing senders not to implement DMARC. > > > x.1 Implement mail domains as DNS domains with domain-level DMARC policies. > > Mail domains are often implemented as DNS domains, but this is not > required. MX records and SPF policies can be attached to a named resource > record or a wildcard resource record, while DMARC policies can only be > attached to a DNS domain. > > Any name that is configured as a DNS resource record can be reconfigured > as a subdomain name supported by resource records which match the subdomain > name, and names that are not in DNS can be added as DNS domain names. Once > all used mail domain names are configured as DNS domains, they can be > configured with DMARC policies. Once this is complete, the SP policy will > only apply to unused and non-existent names. This will permit use of > SP=reject because any such messages will have been unauthenticated at > origin as well as being unauthenticated at reception. This approach is > fully compatible with RFC 7489 implementations of DMARC. > > > x.2 Implement an NP policy > > The NP policy assumes that names used for mail can be reliably identified, > so that names not used for mail can be categorized as not authorized. Two > approaches are used: > > - For mail domain names that are used with SMTP, the name is assumed to > also be used as an RFC5322.From domain name. This is indicated by an MX > record which evaluates to an IP address, or an SPF policy which does not > begin with an ALL term. (RFC 7505 indicates that an MX record which does > not evaluate to an IP address is useful to indicate that a domain does not > accept incoming mail. Based on RFC 7208, content after an ALL term is > ignored, so a policy of "-ALL" indicates that the name is never used as an > RFC5321.MailFrom domain and an ALL term with any other modifier is a > meaningless policy.) > > - For mail domain names that are not used with SMTP, a new TXT record is > defined, with content "DMARCFROMv1". The presence of this TXT record > indicates that the associated DNS domain, named DNS resource record, or > wildcard DNS record should be considered as potentially
[dmarc-ietf] Ticket #11 (and #112) - Proposed language
Below is my proposed language for dealing with the problems that NP is intended to address: - unused DNS names - non-existent DNS names It provides supporting rationale, and provides a more complete solution than anything suggested previously, and ties the design directly to the mailing list problem. I have labelled the sections starting with "X," because I am not sure of the best way to position this text into the flow of the current draft. Doug Foster x. Reducing the scope of the SP policy DMARC introduces a method for the domain owner to state "at time of transmission, authorized emails will always authenticate using DMARC criteria". However,this authentication can be lost in transit if message modification occurs in transit, as discussed in RFC 7960. This possibility can make domain owners reluctant to move beyond sp=none. This is a significant loss, because sp=none opens a vast namespace to domain abuse, including - names that are DNS domains but are not protected by a domain-level DMARC policy - names that are DNS records records rather than DNS names, and cannot be protected by a domain-level DMARC policy - names that are not in DNS at all, and therefore cannot be protected by a domain-level DMARC policy. To mitigate these impacts, it is useful to distinguish names used as email domains from names that are not used for email. Names that are never used for email are never authorized at time of transmission, and therefore can be blocked without concern about in-transit modifications. Several methods are presented for addressing this objective. x.1 Implement mail domains as DNS domains with domain-level DMARC policies. Mail domains are often implemented as DNS domains, but this is not required. MX records and SPF policies can be attached to a named resource record or a wildcard resource record, while DMARC policies can only be attached to a DNS domain. Any name that is configured as a DNS resource record can be reconfigured as a subdomain name supported by resource records which match the subdomain name, and names that are not in DNS can be added as DNS domain names. Once all used mail domain names are configured as DNS domains, they can be configured with DMARC policies. Once this is complete, the SP policy will only apply to unused and non-existent names. This will permit use of SP=reject because any such messages will have been unauthenticated at origin as well as being unauthenticated at reception. This approach is fully compatible with RFC 7489 implementations of DMARC. x.2 Implement an NP policy The NP policy assumes that names used for mail can be reliably identified, so that names not used for mail can be categorized as not authorized. Two approaches are used: - For mail domain names that are used with SMTP, the name is assumed to also be used as an RFC5322.From domain name. This is indicated by an MX record which evaluates to an IP address, or an SPF policy which does not begin with an ALL term. (RFC 7505 indicates that an MX record which does not evaluate to an IP address is useful to indicate that a domain does not accept incoming mail. Based on RFC 7208, content after an ALL term is ignored, so a policy of "-ALL" indicates that the name is never used as an RFC5321.MailFrom domain and an ALL term with any other modifier is a meaningless policy.) - For mail domain names that are not used with SMTP, a new TXT record is defined, with content "DMARCFROMv1". The presence of this TXT record indicates that the associated DNS domain, named DNS resource record, or wildcard DNS record should be considered as potentially in use as an RFC5322.From domain name. Names which are identified by MX record, SPF policy, or DMARCFROMv1 TXT record are considered in use names and are evaluated using the P or SP policy. Names which do not match these criteria are evaluated using the NP policy. This allows unused and non-existent names to be given a stricter DMARC policy than used names. To implement an NP policy, domain owners may need to make DNS changes: - For used domain names that are only identified by an A or record, an MX record or DMARCFROMv1 TXT record is needed to explicitly indicate that the name is used for mail. - For used domain names that are not in DNS at all, a DMARCFROMv1 TXT record is needed to indicate that the name is used for mail. The NP policy does not require that all mail domains become DNS domains, but the NP policy will only be understood by evaluators which use this specification. Consequently, it is preferable to ensure that all mail domains are implemented as DNS domains. x,3 Implement SPF -ALL policies on unused names. Organizations that have configured SPF to protect their valid RFC5321.MailFrom domains may not have taken the extra measure of using SPF to obstruct names that are not used for mail. While not directly part of DMARC, an authentication result of "DMARC=NONE SPF=FAIL" is a more meaningful result than "DMARC=NONE,
