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

[Alessandro Vesely <[e-mail]>]

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:<[e-mail]>
>>>> 
>>>> Received-SPF: pass (domain example.org
>>>>    designates 192.0.2.1 as permitted sender)
>>>>    identity=helo; helo=example.org;
>>>> Received-SPF: fail (domain of [e-mail]
>>>>    denies 192.0.2.1 as permitted sender)
>>>>    identity=mailfrom; envelope-from="[e-mail]";
>>>> Subject: Not using a mail client for this example
>>>> From: [e-mail]
>>>> 
>>>> 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
--