On 5/6/2021 8:02 PM, Douglas Foster wrote:
I have begun data collection on the effectiveness of the MX and A
tests. Wildcard DNS entries increase the frequency of false
positives and reduce the usability of the test. For example,
"msaqq189.ford.com <http://msaqq189.ford.com>" returns a set of MX
results, but I rather doubt that I made a lucky guess and found a
mail domain that Ford Motor actually uses.
You are adding an human element to this that doesn't exist.
At best, all you can do is enforce the protocol requirements, the MUST
semantics for sure, the SHOULD, most of the time (it is not a MUST)
and the possible MAYS. You have to be ready for all that independent
of reputation.
The beauty of the DKIM Policy-based Model that began with DomainKeys,
extended with DKIM which included SSP, reduced to ADSP when splitting
SSP from DKIM-BASE, then abandoned and now DMARC which brought it back
to life by adding Reporting, is the DOMAIN now giving the world a hint
about its operations.
DMARC is very limited to three policies: reject, quarantine & none.
Reject and Quarantine is equivalent to an exclusive, restrictive
policy which gives SMTP transport rejection authorization. Otherwise,
you did nothing with a "none" policy.
There are the protocol rules. The restrictive policies has alignment
rules and there are procedures to getting to these results, like
lookup DNS requirements.
Independent of DMARC, MX is a SHOULD for a domain, you can still send
mail to a domain that does not have MX records. AAAA is obviously a
SHOULD because not everyone is TCP6 ready. Everyone is not going to
have a DMARC record, nor a DKIM record. SSP, ADSP and now DMARC are
the only way to get a DOMAIN policy above and beyond standard SMTP.
SPF is also an extension to SMTP with its own independent requirements
that DMARC MUST match.
So whats the easiest for a domain not to have any trouble with any of
this?
Don't support it. Don't pretend to support it. Just ignore SPF, DKIM
and its add-ons.
SMTP Receivers are not at a point where we can enforce what may not
exist - a domain policy extractable at two points:
SMTP.MAIL FROM: for SPF
SMTP.DATA.FROM: for DMARC
I have proposed that we exploit the SUBMITTER protocol and optimized
this high overhead protocol, by passing the 5322.FROM field to the
MAIL FROM: line
MAIL FROM:<return-path> submitter=5322.from
Now SMTP has the ability to check for the DMARC policy to see how
strong SPF SHOULD be and if its fails or not.
This will allow for the short circuiting and optimization of MAIL data
I/O which today is increasingly getting larger with multi-media data
transfer.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
