Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Alessandro Vesely <[e-mail]>]

On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote:
>> On Jun 23, 2023, at 12:52 PM, John R Levine <[e-mail]> wrote:
>> On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
>>> I agree with John's point that dkim+spf doesn't make sense in the context
>>> of strict DMARC enforcement (I think it provides value for p=none domains
>> 
>> Since the aggregate reports tell you what authentication worked, I don't even see that as a benefit.  There's also the question how many people would even look at a DMARC v2 tag which would be a prerequisite for the auth tag.
> 
> DMARC v1 supports extended tags.  See section 3.1.3 in RFC 7489:
> 
> 3.1.3 <https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3>.  Alignment and Extension Technologies
> 
>     If in the future DMARC is extended to include the use of other
>     authentication mechanisms, the extensions will need to allow for
>     domain identifier extraction so that alignment with the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From
>     domain can be verified.


Eh?  Dkim+spf wouldn't be a new mechanism, as the domain identifier would have 
to be the same.  I'd have cited 6.3:

6.3.  General Record Format
https://datatracker.ietf.org/doc/html/rfc7489#section-6.3

    Section 11 creates a registry for known DMARC tags and registers the
    initial set defined in this document.  Only tags defined in this
    document or in later extensions, and thus added to that registry, are
    to be processed; unknown tags MUST be ignored.

Of course, there will be lots of verifiers who ignore auth=, t=, and ed25519. 
Unfortunately, while we have so many blog posts, we're still missing DMARC 
verifier checks.


>> The idea is that auth=dkim means you'd publish SPF records but hope people will ignore them, or vice versa for auth=dkim?  I still don't get it.
> 
> The immediate benefit would be forwarders. I believe Wei labeled this form of forwarding REM in the PDF analysis posted recently.
> 
> With REM forwarders, in SMTP transport terms, it is a passthru message forwarded to a recorded address given by the local domain or locally hosted domain Recipient , untouched data.  MTA inbound to MTA outbound. The MDA, like gmail.com <http://gmail.com/>, would see an SPF failure so the DMARC auth=dkim relaxed option tells GMAIL that the hard fail with SPF is acceptable, ignore it, but expect the DKIM to be valid from the author signer domain.


SPF hard fail is acceptable even with the default auth=.  (SPF hard fail is a 
problem for those who reject before DATA.  Receiving MXes have no DKIM clue at 
that stage.  The only way forwarding might work without replacing the bounce 
address is if either the receiver or the SPF record provide for whitelisting. 
As a side note, let me add that I'm rejecting way more spam thanks to spf-all 
than DMARC and DNSBL together.)

The auth=dkim (excluding SPF) setting is needed by domains who /have/ to 
include a bloated SPF record in order to deliver at sites which only verify 
that.  However, since the bloated record allows impersonation, they don't want 
that DMARC verifiers consider it.  They probably wish that everybody used DMARC 
so that they could avoid publishing an SPF record, but there's not much they 
can do about it.


Best
Ale
--