Hi Murray, Thanks for this...
> > Forgive me, but doesn't section 8.2 say that forged abuse reports > > constitue a real problem and the two mechanisms available to protect > > against them may result in genuine abuse reports being discarded? > > Yes to the first point. The second point is true of all email, not just > abuse reports; > if the signer's infrastructure is causing signatures to break, there's no > reason to > trust the reports even though they bear some kind of signature. The same goes > for, say, a message from your bank that's signed but the signature fails to > validate. > > > Is the message here "chosse which you think might be the least worse > > problem" or is it "you should use DKIM and SPF, but be aware that you > > may lose some genuine reports"? > > It's "You should use DKIM and/or SPF, but make sure they're working properly > if > you want to reap the benefits." > > > I would have liked some clarification as to which message is being > > sent. > > That section is only talking about reports. Which part is unclear? Simply (to my reading - which you may ignore if you feel I am not reading clearly) that the thought you captured above is not clear. I read a rather despairing statement that since DKIM and SPF might not be working it is a toss-up whether you have reports being discarded because the signature fails or reports being spoofed. If this is "state of the art" for email systems then maybe there is nothing else to say. It struck me, however, that reports are going to be consumed by automatic systems. If I get an email where the signature fails, I can perform all sorts of human verification of the email and make a judgement call on the validity of the email. A software system processing reports is less flexible and so more exposed. Perhaps the clarity that is needed is the strong hint that "Therefore the use of DKIM and/or SPF is RECOMMENDED and it is important to ensure that the security infrastructure is working properly." Cheers, Adrian _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
