On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
I think that we're well past learning anything new in this thread.
SPF is what it is (RFC 7208). DMARC doesn't need to re-invent the protocol
(and shouldn't). For any properly implemented SPF verifier, DMARC should be
able to consume the Mail From result.
Perhaps Courier-MTA is not so properly implemented, but when mail from is empty
it just omits the corresponding Received-SPF: header field.
OTOH, properly implemented SPF verifiers could skip producing a Mail From
result if the helo identity was verified successfully.
In conclusion, the idiosyncratic requirement can hardly be implemented.
On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
I don't see any justification for using HELO unless the SMTP address is
null. If the SPF RFC says otherwise, this should be corrected.
It makes sense to add a section that modifies RFC 7208. See below.
On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:
My data, cited previously, indicates that HELO can be useful for both
blacklisting and whitelisting. It should not be ignored.
On Sun, Jan 31, 2021 at 11:52 AM John R Levine <jo...@taugh.com> wrote:
On Sun, 31 Jan 2021, Alessandro Vesely wrote:
One way to interpret RFC 7489 is that you can put dmarc=pass based on
the helo identity *only if* MAIL FROM is null. >>>
That would be consistent with 7489.
Sec 3.1.2 says
Note that the RFC5321.HELO identity is not typically used in the
context of DMARC (except when required to "fake" an otherwise null
reverse-path), even though a "pure SPF" implementation according to
[SPF] would check that identifier.
Does that mean that an implementation that uses the RFC5321.HELO identity
without taking care of whether RFC5321.MailFrom is empty is *atypical*?
Please note that all the text occurring before that paragraph would suggest
that any authenticated domain, if aligned, would do. The quoted paragraph
comes as a note, by surprise, without bringing any rationale. That text needs
to be revised whether or not we remove the idiosyncrasy.
And the only rationale learnt in this thread is that one could type whatever it
wants in the helo/ehlo command, as if that weren't true for the whole SMTP session.
But then 4.1 says
o [SPF], which can authenticate both the domain found in an [SMTP]
HELO/EHLO command (the HELO identity) and the domain found in an
SMTP MAIL command (the MAIL FROM identity). DMARC uses the result
of SPF authentication of the MAIL FROM identity. Section 2.4 of
[SPF] describes MAIL FROM processing for cases in which the MAIL
command has a null path.
That section of 7208 says that if there's a null bounce address, SPF
pretends that the MAIL FROM was postmaster@HELO.
"Postmaster" is necessary, because SPF mechanisms can refer to the local part.
The SPF part I'd modify, however, is Section 2.3, where it says:
If a conclusive determination about the
message can be made based on a check of "HELO", then the use of DNS
resources to process the typically more complex "MAIL FROM" can be
avoided.
I'd append to that sentence:
, unless downstream filters need it anyway.
Since we're at it, that paragraph continues with the following sentence:
Additionally, since SPF records published for "HELO"
identities refer to a single host, when available, they are a very
reliable source of host authorization status.
Isn't that the exact opposite of what many of us are claiming? And is it legit
for a proposed standard to quietly counter an existing proposed standard
without some kind of rationale?
If we want, we can say not to use the SPF HELO identity, but that would be
an incompatible change to 7489 and I suspect would not match what most
DMARC checking code does.
OTOH, relaxing the requirement that the SPF HELO identity be used only when
MAIL FROM is empty brings no incompatibility. It's just a cleanup.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
