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

[Alessandro Vesely <[e-mail]>]

On Thu 28/Jan/2021 21:40:49 +0100 Murray S. Kucherawy wrote:
> On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely <[e-mail]> wrote:
> 
>>> DKIM (in its simplest form) returns N tuples of the form (d= domain, 
>>> pass/fail).  All of them were run through exactly the same check; all
>>> of them were attached to the message in exactly the same way; all of
>>> them have essentially identical semantics.  Giving them equal footing
>>> makes sense to me. >>>
>>> The two identifiers in SPF hold different places in the SMTP session,
>>> and have different semantics.  I think treating them differently is also
>>> just fine. >>
>> It is relevant that both identifier come from /the same/ SMTP session. 
>> That's not true for many DKIM signatures. >
> I guess if report consumers really want this information, we can include
> it.


Helo is essential if mfrom is missing.  A second SPF identifier is optional anyway.


> I just don't see the value in the HELO parameter if it's effectively
> random junk in the session.


Where does that notion come from?  Most mail admins choose the helo name 
carefully, possibly so that it resolves both ways to the IP number.

I just run a quick test on my current folder.  Out of 3879 messages I extracted 
944 unique helo names.  721 of these matched the reverse lookup exactly.  Out 
of the 223 remaining, 127 had an SPF pass for the helo identity anyway.  So in 
96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining ~90% 
something worth considering?


> At least a passing DKIM signature is associated with a domain that existed
> at some point in time and whose DNS contained apparently-valid public keys.

Why cannot one type DKIM-Signature: d=anyrandomjunk ...?


> I can mostly type anything I want to HELO or EHLO.


That's true for any identifier.  We know an identifier is associated with a 
domain that existed at some point in time only after it's been authenticated.

One may say DKIM authentication is somewhat more precise, because the vogue is 
to include whole classes of IPs in SPF records.  But then, such lack of 
accuracy affects mfrom and helo alike.

The real difference between helo and mfrom is that the former is a 
configuration parameter of the sending relay, while the latter is set by the 
submission client.  The former is akin to d= and s=, while the latter is akin 
to From:.  No rationale to discard either, AFAICS.


Best
Ale
--