On 4/12/23 11:15 AM, Murray S. Kucherawy wrote:
The MLM can then decide if it is willing to pass the message
unmodified to the list, or reject it with an error like "The policies
of this list require modification of your message, which violates your
domain's apparent policy. Your submission therefore cannot be
accepted. Please contact your support organization for further
assistance." There's never an opportunity for the collateral bounce
to occur if the message is never distributed, and the author domain
has to either soften its policy or separate its regular users from its
transactional stuff somehow.
This puts me in mind of Section 8.5, which calls out some potential
impacts of blocking policies to "Mediators," which role doesn't
otherwise appear very often in this document. Is there any need to add
Mediator Actions/Considerations under section 5? Or does this belong in
a separate document?
ISTR there were some vocal and visible mailing list operators that were
rejecting messages from domains that published "p=reject" policies,
maybe around 2014-15? I also thought they did this by checking the
sending domain's published policy in DNS, to your point about
implementation.
In which case I think this approach was tried, and I don't recall it
persisting as a pain point for terribly long - perhaps they moved on to
"unsavory mutations..."
In any case, are we really going to start suggesting that list operators
start rejecting messages sent from domains that publish a blocking
policy, as official guidance? (Now I'm looking ever so forward to
catching up on these other threads - what the heck are people seeing out
there??)
On 4/12/23 11:41 AM, Todd Herr wrote:
My preference here would be to add text for Domain Owners to make them
understand the ways that p=reject might cause some mail using their
domain to not make it to its destination, with "mailing lists might
reject your mail" being one such example.
Yes, it seems like we'd either add something short to domain owner
considerations per Todd, or we'd need to add considerably more to cover
list operators and/or other Mediators.
--S.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
