On 3/29/2023 9:16 PM, John Levine wrote:
It appears that Murray S. Kucherawy <superu...@gmail.com> said:
This is laid out in RFC 6377, Section 5.2, if it would be helpful to have
something published to reference. Indeed, ADSP threatened the same damage
that DMARC "p=reject" causes, which I think was one of the reasons it never
got adopted.
It wasn't just a threat -- someone got bounced off an IETF list shortly
after the ADSP draft came out when some eager beaver implemented it.
I was the one who first reported the problem of what will happen when
the SSP (DKIM Policy) was split from DKIM. I was able to show this
when the IETF was not yet supporting DKIM.
With the split, DKIM became DKIM-BASE and SSP became ADSP with all the
3rd party (re)signer concepts from SSP removed. It went from SSP
policy which considered 3rd party signers:
o=? WEAK (signature optional, no third party)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
to a very limited 1st party only policy.
DKIM=DISCARD always expect to be signed by the Author Domain
DKIM=ALL always expect to be signed but by who?
The only flexibility was DKIM=ALL. We presumed it could allow for a
3rd party signer and it would be useful by mailing list servers.
Unfortunately, we could not resolve how to authorize the 3rd party
signers and ATPS was said not to scale.
So in my view, its not ADSP, DMARC as the problem -- its a lack of a
3rd Party Authorization model in the protocol.
I see more domains are being "dmarca-tized" without their domain owner
knowledge of what the hosting system is doing nor how the MDA hosting
will handle mail. This is causing major problems that requires
drastic mail handling actions.
I now have forwarding mail logic that determine the sender's DMARC
policy. If weak or none it can be forwarded. If strong, it stays for
mail pickup.
I long had mailing list subscripting logic to stop a subscriber with a
strong DMARC policy.
I will probably begin to add a From Rewrite but I would prefer if the
DMARC record has a domain authorization to do so, with perhaps a
`-rewrite` tag to signify any form of rewriting allowed.
I think we need to focus more on DMARC having extended tags that
address many of the issues and ideas we have encountered. Receivers
want to honor the author domain wishes for handling failure when
various parts fail to meet their protocol-defined expectations. But
if honoring going to cause more problems, then we either abandon DMARC
like we did with ADSP or we add 3rd party domain considerations.
Reject domain polices should support these ideas for handling outbound
and inbound mail handling.
-p=reject -rewrite -atps
-rewrite
says if the first initiate signer succeeded and you need to resign,
then you are allowed to rewrite the ADID. This handles list
distribution problems. If a domain does not have -rewrite, a
subscriber and list submission MUST be denied.
-atps
says if we ADID does not equal SDID then we will do an SDID ATPS
lookup at the ADID zone. This handles reception for all mail. If a
domain does not have -atps, then the receiver MUST honor the domain
reject policy for failures.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
