Scott Kitterman writes: > 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.
True, thats why the proposed text also says you SHOULD NOT put 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. It would be much better when people would really remember that having valid or not valid DMARC/DKIM/SPF for email does not tell anything whether the email is bad/spam/unwanted. Regardless whether the DMARC/DKIM/SPF is valid you always need to use other methods to filter emails, so as you need to do that anyways while receiving emails, there is no problems of using same things also for p=reject messages. You can use the failed dmarc with p=reject as one of the inputs to feed your actual email filtering system, the dmarc p=reject SHOULD NOT BE your only email filtering system. -- kivi...@iki.fi _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
