Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Hector Santos <[e-mail]>]

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