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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
