To return briefly to the muddy waters that I created. John is correct that "mail enabled" is not useful for the RFC5322.From address, and my last note expanded on reasons why that is correct.
However, spoofing of non-existent subdomains is a potential problem for the RFC5321.MailFrom domain, which then becomes an attack vector for the RFC5322.From address as well. The problem exists because because SPF has no organizational default. We need to think about intermediate nodes, non-mail leaf nodes, and non-existent subdomains. Assume that a spammer tries to spoof a legitimate organization by using a non-mail or non-existing node for both the SMTP MailFrom address and the message From Address. The message will be evaluated as - SPF=None, - DomainAligned=True, and - (if checked by some unknown algorithm) OrganizationReputation=good. Can we assume that all such messages will be blocked by all recipients? It seems better to have a published policy to say that it should be blocked. Based on existing specifications, the organization has these defenses: - All possibilities are protected if the organization DMARC sp policy is enforceable (p<>none and pct<>0). However, we know that this is problematic for many organizations. - Mail-enabled nodes should have an SPF record, so those domains will be protected. - Existing but non-mail domains are only protected if they have an SPF -ALL policy. This may be difficult and error-prone for the organization to maintain. Conclusions: Assuming that many organizations are still at sp=none, we have an attack surface from non-existent domains. The "must exist" policy provides the only defense for non-existent nodes when the DMARC sp policy is non-enforcing. Assuming that many organizations will have trouble managing deployment of SPF -ALL universally, we have an attack surface for non-mail subdomains. The "must be mail enabled" policy provides a simpler defense mechanism than deploying SPF -ALL to every non-mail node. DF -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Chudow, Eric B CIV NSA DSAW (USA) Sent: Friday, November 20, 2020 6:29 AM To: 'John Levine'; 'dmarc@ietf.org' Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thank you, John. I agree that it's an edge case and not worth addressing separately. Eric Chudow DoD Cybersecurity Mitigations -----Original Message----- From: John Levine <jo...@taugh.com> Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) <eric.b.chudow....@mail.mil> Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP In article <553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. 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
