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... -- kivi...@iki.fi _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
