On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote:
On Jun 23, 2023, at 12:52 PM, John R Levine <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
