On 13/May/11 20:17, Murray S. Kucherawy wrote: >> From: On Behalf Of SM > By my read, the bulk of your comments fall into these categories: > > (1) Remove the normative language, publish as Informational
My reading of SM's comments is for replacing "Best Current Practices", not normative language in general (but in particular, where it is redundant.) I consider his thoughts in accord with what another John noted: When we make that sort of recommendation in a BCP, we expose ourselves to the criticism that the recommendation is neither best (as distinct from a bad compromise), nor current (as distinct from a recommendation about future behavior), nor actively practiced. > 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. -1, I'd favor AS/PS or even experimental over BCP, but still prefer BCP over informational. > As for the idea of using PS instead, that doesn't seem appropriate > to me given we're not standardizing a protocol here, and at best we > don't have enough implementation experience to back up the claims. How about running a test? I guess many of us can configure their MTAs for signing/verifying as it requires... > (3) RFC5451 discussion >> This falls under policy decision. The usage of a 554 code is >> inappropriate. From Section 3.6.2 of RFC 5321: >> >> "If it [SMTP server] declines to relay mail to a particular address >> for policy reasons, a 550 response SHOULD be returned." > > 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. Yes, my understanding of that SMTP snippet is that it concerns responses to RCPT TO:<particular address>, while DKIM and ADSP can only be evaluated after <CRLF>.<CRLF>. (In this respect, mentioning "user unknown" in the MLM spec may cause some confusion in readers not familiar with SMTP.) > 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. +1 for keeping 554 as is. > But to be conformant, I suppose 550 5.7.0 would be appropriate. Conformant to what? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
