On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang <weihaw= 40google....@dmarc.ietf.org> wrote:
> Regarding the languages in section 8.6 "It is therefore critical that > domains that host users who might post messages to mailing lists SHOULD NOT > publish p=reject. Domains that choose to publish p=reject SHOULD implement > policies that their users not post to Internet mailing lists", we wanted to > point out that this is impossible to implement. Many enterprises already > have "p=reject" policies. Presumably those domains were subject to some > sort of spoofing which is why they went to such a strict policy. It would > be unreasonable to tell them to stop posting to mailing lists as many > likely already use mailing list services and will want to continue to use > them. The one thing that makes this tractable is the SHOULD language as we > may choose not to not follow this aspect of the specification. Our > suggestion is that there is not a lot of value in including this language > in the bis document if the likely outcome is that it will be ignored, and > rather more effort should be placed with a technical solution for interop > with mailing lists. > Speaking as a participant: I don't think it's impossible to implement generally. Google (the company, not Gmail the service), PayPal, Yahoo, and Facebook (when it was called that) all found ways to mitigate the damage DMARC causes by moving their human users (i.e., employees) into domains separate from their services. That allowed the commercial stuff to go "p=reject" while the humans weren't so constrained. Of course the cost is that you have to move all of your human traffic to a new domain, but that doesn't strike me as "impossible" so much as inconvenient because they all did it. As for Gmail itself, I think that argues for SHOULD NOT being the right thing to say, although I still think that sends a weaker-than-desirable message about interoperability. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
