Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos <[e-mail]>]

On 3/29/2023 9:16 PM, John Levine wrote:
> It appears that Murray S. Kucherawy  <[e-mail]> 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