On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote:
On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:
On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:
On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:
On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:
On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
I doubt that SPF filters report envelope-from=postmaster@HELO; more
likely they write helo=HELO. In that case, the paragraph quoted above
is deceptive.
I believe the proposed text is clear enough about not using
separate HELO identity results and that's appropriate. >>>>
My filter collects SPF results recorded from an upstream SPF filter.
It writes Received-SPF: lines for each identity. For NDNs, it writes
a Received-SPF: for the HELO identity only. Am I allowed to use that
result for DMARC?
No. You should only use Mail From results.
So NDNs having only an aligned HELO will never pass DMARC?
And what is a <scope>helo</scope> element in aggregate reports provided
for?
The spec says:
[SPF] can authenticate either the domain that appears in the
RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
HELO domain, or both.
And then:
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
domain must have the same Organizational Domain. In strict mode,
only an exact DNS domain match is considered to produce Identifier
Alignment.
So, consider the following message without DKIM signatures:
HELO example.org
MAIL FROM:<[email protected]>
Received-SPF: pass (domain example.org
designates 192.0.2.1 as permitted sender)
identity=helo; helo=example.org;
Received-SPF: fail (domain of [email protected]
denies 192.0.2.1 as permitted sender)
identity=mailfrom; envelope-from="[email protected]";
Subject: Not using a mail client for this example
From: [email protected]
Does it pass DMARC?
No.
Let's not be silly, Scott. We have example.org as the SPF-authenticated
domain and it is aligned with From:. Are you saying that the message
would pass if it had an empty bounce address, but since it can bounce it
does not pass?!? >
All I'm saying is that DMARC only uses mail from results and that's
appropriate. I don't think the case of HELO name being aligned, but mail
from domain is not is one to worry about.
That's abnormal, not appropriate.
AFAIUI, there's no reason why SPF would work with a logic substantially
different than DKIM's. DKIM can provide n identifiers, if one of them is
aligned and "pass", then DMARC is "pass". SPF can provide 2 identifiers but
one of them is of class B. WTF?
Can anyone explain why we have a <scope>helo</scope> element in aggregate
reports?
Can we fix this aberration?
The spec needs a fix anyway, because from the text I quoted above I understood
that the example message passes DMARC. Am I the only one?
In addition, as I said, SPF filters are likely to report HELO as helo and MAIL
FROM as mailfrom. If we want to carry over this quirk, the spec must say that
a DMARC filter which gathers SPF authentication status from an upstream filter
MUST make sure that mailfrom is empty before validating based on an aligned helo.
Dropping that absurd discrimination between SPF identifiers would make for a
smoother spec. Since non-null mailfroms are in most cases aligned with either
From: or helo, the differences between existing compliant implementations and
the smoother spec would be limited to a hardly noticeable set of test messages.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
