On Sat 10/May/2025 22:35:44 +0200 Wei Chuang wrote:
On Wed, May 7, 2025 at 5:42 AM Alessandro Vesely <[email protected]> wrote:
On Wed 07/May/2025 00:18:41 +0200 Wei Chuang wrote:
forwarders will likely also want a say in what happens to a message that fails
validation.
In order to keep it simple, I'd conceive the author domain, the one in From:,
to be the "owner" of the message.
If DKIM2 header algebra yields more than one valid From header, we may want
to consider an algorithm to select which one is the owner. Presumably this
should be the earliest, though for DMARC reporting perhaps both can be
considered.
The real case is lists writing [email protected]. When I can
revert the MLM transformation, I restore the original From: field, especially
for the recipient's use. For reports, the question is whether the author
domain wants to know. People set p=quarantine; pct=0 (now t=y) in order to
avoid reports showing DKIM verification errors.
Do we expect From: munging to still be necessary with DKIM2?
we propose that the forwarder domain be able to publish a policy that
specifies the forwarder's intent on what enforcement to apply.
This sounds to me like an affected complication. When authentication works
well, there will be no reason to specify weal policies. Until then, let the
owner decide.
To me this is a fair standpoint from a receiver perspective. My guess is
that the benefit is marginal to support forwarders compared to the extra
DNS policy lookup cost borne by the receivers. The forwarding idea is
really a strawman to explore the cost benefit.
A lookup is needed to learn the reporting address anyway. But if From: is not
munged, receivers learn the forwarder domain from the signature. In that case,
why should we lookup _dmarc.forwarder.example rather than, following RFC 6651,
_report._domainkey.forwarder.example? (BTW, the upcoming DMARC spec already
introduces some conflation between the two.)
By default the "rua=" and "ruf=" tags specify where the forwarder reports
may go. However forwarders may specify a different location "frua=" and
"fruf=" to distinguish forwarding traffic from origination traffic in the
reports.
Rather than a different reporting address, I'd specify additional report
attributes that identify unambiguously which forwarding chain the messages
belong to.
It'll be more specification work this way though it may permit additional
capabilities to express details around the forwarding as observed by the
receiver.
Signing domains and selectors are already there. It might be enough to add the
i= sequence number, so that A->B->C and B->A->C are reported (by C to both A
and B) as different streams.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
