On 6/5/2020 6:34 AM, Alessandro Vesely wrote:
4) Require all recipient systems to make special policy accommodations to grant
trust to messages from List B, simply because it comes from List B. This is
feasible, but specific to each participants incoming email filter.
This is a hindrance to DMARC adoption. The need to catch and mark all the
mailing list domains that don't rewrite From: can prevent an MTA from blindly
conforming to all DMARC policies. Alternatively, an MTA can mark highly abused
domains and conform to DMARC policies in those cases only.
It doesn't have to be all mailing list, just the ones authorized to
resign on your behalf. Of course, there are scalability issue with
the "bigger guy" but that should not preclude the "smaller guy" from
leveraging this method.
For completeness, I'd also mention conditional signatures, as a fifth point.
They were specified, implemented and then abandoned in lieu of ARC.
hmmmm, interesting. Where was the "Conditional Signature" proposal
implemented? I have never come across a conditional signature header.
I was not aware ARC was a "conditional signature" or "3rd Party
Authorization" protocol. IMO, ARC has a high barrier of entry with an
awful amount of complexity to implement in order to authorize a 3rd
party domain.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
