The point isn't to place blame. The point is to specify how to maintain interoperability, and in the case of DMARC p-reject there are two places where we can lessen the interop problems: telling the senders not to use p=reject in inappropriate conditions, and telling the receivers to consider the interop issues when honoring the p=reject policy. The latter is necessary partly because some senders will ignore the former... but it is also necessary because even in cases where p=reject *is* used as it was intended, some legitimate mail will get caught up by it and judgment is important.
None of this text is meant to chastise or blame. Barry On Sat, Jul 8, 2023 at 2:25 PM Scott Kitterman <[email protected]> wrote: > > > > On July 8, 2023 6:16:46 PM UTC, Tero Kivinen <[email protected]> wrote: > >Brotman, Alex writes: > >> I suspect the portion that instructs receivers to not act solely on > >> p=reject may be ignored by a fair set of receivers. I'm not > >> necessarily opposed to the language below, just that it seems odd to > >> create language that we know will be ignored. > > > >If receivers ignore that, then at least we can complain to them and > >say that you should not do that, as the RFC says you should use other > >information too if they want to get important forwarded emails > >through. For example we in iki.fi have been regularly been helping > >people with their broken spf etc records which break forwarding, and > >several times we have actually managed to explain the situation and > >they have change their settings. Quite often those people simply > >follow whatever some consultant etc suggested, and they did not > >understood at all that they at the same time broke other things. > > > >Quite often they do want to reduce the amoung of support calls, and if > >they get support calls every time some forwarded email from mailing > >list or from forwarding gets rejected, they most likely will notice > >that and fix their setup. > > > >> Additionally, I find it odd that we won't tell forwarders how to > >> munge messages to avoid this situation, but we will tell receivers > >> how to avoid this situation. > > > >There is no good way for forwards to mungle message in such way that > >return path/DKIM/user expectations stays intact. I myself for example > >find the From address mangling done by this mailing list really > >annoying as I need to use extra time to parse the =40 addresses to > >find out domain name of the sender. > > > >For mailing list this is just annoying but you can do that, but for > >regular forwarding you can't do that as you want to keep the DKIM > >signature intact. > > > >And this problem is not generated by forwarders, it is generated by > >the receivers who only use DMARC and no other information while > >rejecting emails. So there is no point of asking forwarders to fix > >things that was broken by DMARC... > > You can equally argue that these receivers are merely following the policy > advice provided by the sending domain (it has reject right in the name) and > this problem is entirely generated by sender's inappropriate use of p=reject. > > I don't think engineering the location where the blame lands is the right > place to focus. I've done plenty of blame avoidance engineering in my day, > but I don't think it's what the IETF should be doing. > > Scott K > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
