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/). 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
