On Feb 23, 2009, at 12:32 AM, Murray S. Kucherawy wrote:
On Sun, 22 Feb 2009 13:11:26 -0800, Doug Otis wrote:
This appeal boils down to "someone might misuse it so don't
standardize it." Is there any standard to which someone couldn't
have made a similar objection?
The appeal is in regard to offering recipients potentially
misleading information where its source is intentionally omitted
thus preventing reputation evaluation by the MUA as required by
section 4.1.
This assertion, which is the premise behind much of the logic within
the appeal and its varied antecedents, is manifestly false. The
draft not only does NOT establish that requirement, it goes to some
length to suggest doing so is a bad idea.
Review the first sentence of the fourth paragraph of section 4.1.
,---
An MUA SHOULD NOT reveal these results to end users unless the results
are accompanied by, at a minimum, some associated reputation data
about the authenticated origin identifiers within the message.
'---
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP
client as a weakly "authenticated origin identifier". The IP address
of the SMTP client is the input for Sender-ID or SPF *authorization*
mechanisms. Checking the reputation of the "authenticated origin
identifier" determines whether this identifier protects the message
elements used to establish the *authorization* prior to revealing the
*authorization* results.
Appendix D of the draft pertains to the rejection of messages at
border MTAs, and to not repeating verification processes that border
MTAs should perform. Neither of these functions is being sought by
the appeal.
The appeal seeks a means to check the reputation of the "authenticated
origin identity" to determine whether it might be safe to reveal
results of an *authorization* mechanism. This requirement is clearly
stipulated by section 4.1. Again, this is not about whether to block
or reject messages or repeating a verification process, this about
determining whether it might be safe to reveal authorization results.
Checking the authorization protections offered by the IP address of
the SMTP client, prior to revealing that an IP address has been
authorized, represents an essential element needed to ensure security.
Border MTAs have shown a willingness to make assumptions about
authorization, and about the SMTP client's protection of the elements
used to obtain the authorization. Unfortunately, when either of these
assumptions are incorrect, this allows bad actors a means to obtain
credentials that are likely to dupe their victims. With all the
uncertainties involved as to whether authorization is intended, or
whether authorization elements are protected, limiting reputations to
just authorizing domains will create irreconcilable conflicts between
sender, receiver, and MUA.
In addition, including the IP address of the SMTP client makes the
header less deceptive. Recipients must consider which identifier has
been authenticated. It is the *authenticated* IP address of the SMTP
client that is being *authorized* by Sender-ID or SPF. Using this IP
address to replace the local-part avoids the conditional inclusion of
the local-part that is required by section 2.4.3. This section
confuses authorization with authentication where even local-part
authorization can only be determined after examining internal elements
within SPF records. Tracking the *authorization* role of the local-
part is not a defined output of either authorization mechanism, nor is
it safe to process SPF record local-part macros!
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf