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 <ves...@tana.it> wrote: > > On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote: >>> On Jun 23, 2023, at 12:52 PM, John R Levine <jo...@taugh.com> 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 > -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
