[dmarc-ietf] Rethinking DMARC for PSDs

["Douglas E. Foster" <[e-mail]>]

I understand how much work it takes to create consensus toward an IETF 
standard, but I suggest that the problem needs to be re-examined because 
DMARC for PSDs seems to be neither the sufficient solution nor the 
necessary one.
  
 The problem:
  	Spammers use non-existent domains to achieve identity spoofing, such as 
tax.example.gov.uk 
 This is primarily a reception problem, because many recipient mail filters 
are not equipped to block this type of fraud.  However, domain owners are 
also concerned about protecting their reputation from fraudulent material 
sent using their identity.
  
 These two sender-receiver combinations are already protected from the 
problem:
  	Recipients with DMARC enforcement enabled if the message comes from a 
parent domain with DMARC-enforcing policy. 	Recipients who filter for 
non-existent domains, regardless of parent domain or receiver DMARC 
capability. 
 These three sender-receiver combinations currently have no protection:
  	Any recipient when the sender does not request DMARC enforcement (and 
non-existent domain filtering is also off.) 	Any recipient who lacks both 
DMARC enforcement capability and non-existent domain filtering.. 	Any 
recipient when the parent domain is a PSD (and non-existent domain 
filtering is also off.) 
 The DMARC for PSD standard will only protect the last category of 
unprotected recipients.
  
 What can we assume about legitimate usage of non-existent subdomains?
  	Non-existent subdomains support application-generated messages, not 
personal ones. 	Some messages will be transactional, where the recipient 
expects the message and will whitelist as necessary to ensure delivery. 
	Some message will be marketing related, as a tool to support data 
collection related to specific marketing campaigns.  The recipient probably 
does not expect the traffic, and is not likely to whitelist the traffic.   
The sender relies on the probability that most recipients do not filter on 
non-existent domains, so their non-standard business practice has minimal 
consequences for the sender. 	Possibly, some government cyber-warfare or 
cyber-intelligence operations use this feature.   Whether this is 
legitimate or not depends on the government involved.   It is unlikely that 
the recipient will consider the usage appropriate. 
 Is there justification for IETF to tolerate or tacitly permit messages 
from non-existent domains?
  	No.   Before SPF, there was no method for a sender to announce a 
transmit-only domain, but that problem was solved a long time ago.   Based 
on existing IETF standards, it is reasonable to conclude that: 	 		If a 
domain has not published either an MX record or a SPF record, then it is 
not a legitimate source of email.   Obviously, domains with no NS record 
are also included 	

 Given all of the above, I hope the real solution is clear:
  	We need to encourage recipients to block messages from non-existent 
domains (any domain that has no MX or SPF record published.)  Whitellisting 
should be used for exceptions.  Domain registration is not difficult and 
involves minimal cost, so there is no real justification for legitimate 
senders to maintain sloppy business practices. 
 Implementation methods:
  	Obtain a quorum of major mail-receiving organizations to announce that 
they will no longer accept messages from domains that are non-existent or 
not mail-enabled via an MX or SPF record  (effective no later than 
mm/dd/yyyy).  Exceptions require application on  their registered-sender 
site, with justification.   I expect that Google GMail and Microsoft 
LiveMail would be sufficient to be considered a quorum, and I assume they 
are represented on this distribution list. .The government domains could 
decide whether the best political strategy is to join the initial 
announcement or to mimic it shortly thereafter.
	  	Encourage mail filter vendors to provide non-existent domain filtering 
capability in their products, with the ability to confirm whitelisting as 
requested by the system administrator.   .The major cloud-based email 
filtering services can add this protection to their clients, if it is not 
already present in their products.   This brings another large group of 
recipients under protection 
	  	To ensure that every recipient can implement non-existent domain 
filtering, it would be beneficial if non-existent domain checking becomes 
implemented as a Reputation Block List:   When an email filter requests an 
RBL check on the domain name, the RBL checks for existence of at least one 
MX or SPF record.  If none is found a reject address is returned.  Since 
every email filtering product that I have encountered has support for RBL 
checking, this provides potential coverage for all recipients everywhere, 
and quickly.
	  	If IETF wants to provide a standards-based mechanism for mail-enabling 
a non-existent subdomain, this could be done as follow-up, using TXT 
records in the parent domain.  Once promulgated, it would only be useful 
for senders who know that their recipients have email filters which apply 
the new standard.   Outside a limited distribution group, this is not 
something that the sender can ever know.   Consequently, I do not see this 
as a particularly useful undertaking, but I have no objection to it.   
Those who do not want to depend on recipient whitelisting should register 
their domains and publish an SPF record.   
 It seems like this approach should be able to solve the whole problem in 
less than 6 months.
  
 Have I misunderstood the problem, or misunderstood your solution to it?
  
 Doug Foster