[Apologies for the double-send; the headers got munged by my editor. -MSK] Doug Otis wrote: > [SPF/Sender ID debate omitted] The draft points out in its Security Considerations (section 7.7) that issues which may exist in the message evaluation methods it covers apply here as well, and admonishes implementors to be aware of them. The context of this draft is not the place to re-open those old debates. That this draft names SPF and Sender-ID as current methods does not endorse or promote them. The text is explicit about this as well (top of section 4). It merely acknowledges that they exist and are popular, and thus enables the transmission of the output of those evaluations for sites that use them. > [...] while omitting the IP address of > the SMTP client. This prevents compliance with section 4.1 reputation > check of an authenticated message origination that is needed to > mitigate highly disruptive and injurious situations. No, it doesn't. An implementation can be perfectly compliant in other ways, such as doing the reputation evaluation (be it IP or domain name) at the border MTA. There are a lot of good reasons for doing it that way too discussed in the draft (and, in fact, reasons not to do it elsewhere). > Placement within the authentication header has been made dependent > upon an undefined and unsupported notion as to whether a local-part > had been used to obtain authorization. [...] Your assertion presupposes no SPF implementation knows, or is capable of knowing, whether or not it expanded a local-part macro. Even if the former is true, it's hardly a difficult thing to add, and the user of an SPF module can easily err on the side of safety and assume that it wasn't in either case. The normative text in this draft covers that possibility. SM asked: >> Are there any implementations of the technique you are suggesting? >> The feedback received from other implementors showed that they >> neither use the above technique nor do they support your point of >> view. I'd really like an answer to that question as well, since the work in the draft is based on a number of real-world implementations that simply don't do it the way you envision. You seem, however, to prefer to dodge that challenge. > By including the IP address of the SMTP client, a > reputation check of the SMTP client allows its Sender-ID "pass" > results to be ignored when it fails to protect the PRA. ..which could be done at the border MTA, as it has the IP address of the SMTP client. Why do you insist that there is a need to repeat at the MUA work that's already been done at the border MTAs (where experience suggests it belongs)? > Why preclude an important option, and a necessary > check as stated in section 4.1? There has never been any reasonable > justification for omitting the IP address of the SMTP client. This IP > address must be passed to the SPF record evaluation process! It's not precluded, it's explicitly required. It's just not the way you'd like it done. > Importantly, the recommended remedy allows annotating a message to > remain complaint with section 4.1 which states the reputation of the > _authenticated_ origin of the message be checked first. You seem to be reading more into that language than exists. Section 4.1 says the reputation has to be checked, but makes no assertion that it has to be checked at the MUA. In fact, the draft contains a substantial amount of guidance about the fact that such an architecture is possibly even detrimental. Moreover, the "issues" rebuttal draft you posted contradicts itself. For example, your section 1 claims: "While there are cases where a domain is controlled by a bad actor, often use of the bad domain is brief." This is an argument against your own proposed remedy. The claim implies that timely evaluation of reputation, i.e. when the message is in transit, is important. Users, however, might read the delivered messages hours or even days later. It follows that the active part of mail delivery (the MTAs), rather than the passive part (the MUAs), is where such evaluations must be done. Thus, doing such evaluations when the MUA opens the message are not very valuable. Your remedy, therefore, contradicts one of your premises. Finally, I'm afraid your theories about the motivations of this draft's proponents are rather contrived. Some of the issues you brought up regarding the draft, as well as the results of the IESG review (which dealt with guidance language rather than technological issues), were incorporated into its most recent versions. You've been pushing this stuff, i.e. the remainder of your concerns, for months now without any substantive support on any of the lists to which you keep sending them, including during IETF Last Call which ended more than a month ago. Now, can we please, please move on? -MSK _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf