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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf