> 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: https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3 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. > > 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. Who sets this tag? The initial sender that unbeknownst to this sender, the MX Is not the final MDA. We will never know that information of where a contact can be reached. The Hosted Domain market is very big and important. So it will be a matter of training system admins that domains with any chance of being indirect, it will probably be a good idea to use a relaxed SPF evaluation for DMARC1. We will not need a version bump. — HLS
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
