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

[Hector Santos <[e-mail]>]

Alessandro,  I believe we are on the same wave.  I support the DMARC1 tag extension `auth=‘ idea.   Do you have any suggestions for the text?  

Technically we don’t need DMARC1-Bis.   That document can move forward as is and a new draft proposal I-D called “DMARC1-EXTENSION-AUTH” can be written for relaxing the original DMARC1 (RFC 7489) and also the current DMARC1-bis.

—
HLS

> On Jun 24, 2023, at 12:17 PM, Alessandro Vesely <[e-mail]> wrote:
> 
> 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
> --