On Tue 12/Oct/2021 13:42:06 +0200 Douglas Foster wrote:
From a security perspective, Ale's proposal is flawless. But I don't like
solutions that make the recipient bear most of the costs of the list's
actions.
Consider sites using p=quarantine; pct=0;. Their mail admin chose to have
From: munged in exchange for aggregate reports free of "failures".
Unmunging creates a high cost of entry for new domains:
To collaborate costs more than doing nothing.
Under a collaboration solution,
These are both collaborative solutions. The first is non-munging, the second
unmunging.
[Under the non unging solution] the subscriber goes to her email support
and says,"I joined list X, and they say that for the best user experience,
we need to configure a whitelist entry to bypass From Filtering on messages
from one SPF-verified SMTP address. Then I need to give them a response
whether this change has been implemented or not."
At receiver, the filter skips DMARC check for a specific SPF-verified address.
At MLM, a filter skips From: rewriting for specific receivers.
Under an unmunging solution, the subscriber conversation is more like this,
"I joined list X, and they say that for the best user experience, we need
to configure an unmunging MTA. Hope this is not too much trouble. I hope
you can get this implemented quickly."
At receiver, the filter skips DMARC check for a specific SPF-verified address,
and restores From:'s content from Author:'s.
The total cost looks about the same. However, both examples assume an overly
collaborative mail admin at the receiver. For a realistic case, we need
unmunging software which works out of the box.
Best
Ale
--
Unmunging note: In neither of Doug's messages I could verify Gmail's
signatures, due to IETF's code adding a '>' in front of "From ". For Laura's
message I got dkim=pass reason="transformed" header.d=wordtothewise.com;. So I
could have unmunged it, in case.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
