Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Hector Santos <[e-mail]>]

On 2/1/2021 7:11 PM, Douglas Foster wrote:
> I think I finally understand the complexities of this issue.   SPF is
> two different validations, largely unrelated.
>
> Test One:
> A connection comes in and a server asserts a HELO name.   Before
> proceeding, the recipient was to check if the HELO name is plausible
> or fraudulent.    One way to do this would be to forward-confirm the
> HELO DNS name to the source IP.  An alternate method is to use SPF to
> see if the SPF policy says that the HELO domain can send from the
> Source IP.   I do not understand why the domain owner would be able to
> configure the SPF policy but not the host name in DNS.

There is a history of Machine Host Name and IP misconfiguration -- 
EASILY possible by simply moving a machine or trying to use many 
machines correctly and generically with one configuration profile.  If 
rDNS is not available for the host, its all part of the unreliability. 
  Unless you write SMTP code for outbound mailing, its hard to see 
this. You can try to automate the smtp client design so that the EHLO 
is always correct with the IP, but there will be MANY times where it 
won't be right for ABC customer for their XYZ reasons.  Its possible 
but its not without optional fields to override an automated logic.

> Test Two:
> If the conversation proceeds past HELO to MAILFROM, then the second
> validation is performed:   Is the Source IP is authorized to send on
> behalf of the SMTP domain?   When the SMTP address is null, then
> postmaster@HeloDomain serves as a proxy for performing this test.

That's one theory possible, but the main thing to remember that a 
BOUNCE is required in the name of mail delivery and notifications when 
delivery fails. You still have the unreliable nature of HELO checking 
and a bounce is too important to be making it dependent on an 
unreliable HELO SPF check.

Many systems do a variety of RFC5322 checks for a BOUNCE message after 
it is accepted or maybe at the DATA state.   It would be nice if we 
could enforce DSN (RFC3464) but that is not possible.  Its optional 
and the old way of doing BOUNCE messages, formats and layouts varies. 
  Inconsistent.  There are some keep addresses that "must" or "should" 
exist in the 5322.From, like the user part has "Mailer-Daemon" and 
"postmaster" when the 5321.MailFrom is NULL.  If not, it could be 
rejected then.

Finally......

Back in early days of LMAP "Lightweight MTA Authentication Protocol" 
[1] , 2003, 2004, Meng Wong made his version of a LMAP protocol called 
SPF. Before SPF, there were others like DMP "Designated Mailers 
Protocols" [2] and RMX [3]. SPF is a merge of these two LMAP methods.

My wcSMTP was among the early LMAP explorers (wcSMTP had DMP support 
before SPF came). I did an LMAP analysis and provided it to Meng Wong. 
  We had an email conversation about the need to document SPF 
CheckHost() for HELO (despite its unreliability and ambiguity) but do 
not enforce HELO checking because there will a wide degree of 
different implementations possible when it comes to HELO checking and 
the order of checking the identities.  For example, in wcSMTP, the 
order is as follows:

1- RCPT TO
2- MAIL FROM
3- EHLO/HELO (optional which is OFF by default)

Before any extended, DNS overhead augmented technology is performed, 
RCPT TO is checked for validity and existence. So when the client 
issues MAIL FROM, the following response is issued by wcSMTP:

C: MAIL FROM:<return-address>
S: 250 <return-path>... Sender validation pending. Continue.

Then the RCPT TO issued:

C: RCPT TO:<forwarding-address>

If the RCPT TO address is good, then it now checks the envelope 
parameters against a suite of protocols that include RBL, SPF, CBV and 
local rules filters.

But if the RCPT TO address is not good, then a 550 is issued because 
there is no need to check for any DNS related policies.  If SPF fails 
here, DATA is never reached -- its considered an optimizer and 
remember please, SPF predated DKIM POLICIES (SSP, ADSP and DMARC).  In 
additional, there is the PRA and SUBMITTER protocol that wcSMTP SPF 
implementation considers.  PRA/SUBMITTER provides the 5322.From 
address at the SMTP level.  It can be used to for SPF checking. Its 
optional.  But now with DMARC, I think PRA/SUBMITTER can play a big 
role and enhance these DMARC SMTP/SPF checking adjustment. Its 
unfortunate there isn't another "mail engineer" that can see the 
benefit of these protocols used together. SPF doesn't need to change, 
DMARC does!!!

Here is the LMAP analysis I did. wcSMTP follows the concepts this 
analysis to help optimize LMAP protocols checking at the SMTP level:

https://secure.winserver.com/public/antispam/lmap/draft-LmapAnalysis1-2.htm

I hope this helps your understanding of the complexity of all this, 
but for me, there are some basic filter concepts that can be applied 
and I do for my wcSMTP package before all the extra DNS overhead can 
be applied.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

[1] Lightweight MTA Authentication Protocol (LMAP) Discussion and 
Applicability Statement, 
https://secure.winserver.com/public/ietf/drafts/draft-irtf-asrg-lmap-discussion-00.txt

[2] Designated Mailers Protocol (DMP), 
https://tools.ietf.org/html/draft-fecyk-dmp-01

[3] The RMX DNS RR and method for lightweight SMTP sender 
authorization, https://tools.ietf.org/html/draft-danisch-dns-rr-smtp-03