Hi Murray, At 11:17 13-05-2011, Murray S. Kucherawy wrote: >By my read, the bulk of your comments fall into these categories: > >(1) Remove the normative language, publish as Informational > >As I said to John, I'd be fine with this. The document started out >as Informational but there was working group momentum in the >direction of a BCP instead, hence the conversion to use of RFC2119 >language. I personally don't have strong feelings about that so if >the preferred course of action is to go back to that, I'd be fine.
Ok. >Yes, I believe they are consistent. The citation you made from >RFC5451 directs implementations to delete forgeries (the MUST) and >optionally delete everything else as well (the MAY). The citation >from this document does not dispute the MUST, and provides further >guidance for this particular application (which is also consistent >with other parts of RFC5451) in terms of how to deal with what's >left after the MUST part is done. Ok. >3.6.2 applies to relays, not recipients. A relay might try DKIM >validation and ADSP evaluation, but that's not the model this >document discusses. > >However, if that doesn't matter, unfortunately this makes the >distinction we're trying to make impossible without using enhanced >status codes, which aren't universally used. But to be conformant, >I suppose 550 5.7.0 would be appropriate. You can use 550 5.7.1. The enhanced status code used in the draft is appropriate. Thanks for the quick response. BTW, I forgot to the "best current practices" in Section 8. It's an editorial nit. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
