On Nov 12, 2008, at 2:32 PM, Murray S. Kucherawy wrote:
J.D. Falk wrote:
Yep, we've seen some of these already -- particularly in webmail --
and there's been a lot of discussion of how best to do it. Firefox
add-ons like WOT are basically the leading edge of implementation.
As I hinted earlier, though, I the core of this is usability -- how
the information is displayed, and how users interact with the
information -- rather than underlying nomenclature.
In fact, the results of domain and/or IP reputation queries were
some of the things I had in mind when making this proposal
extensible. I just haven't codified any since none have been moved
through any kind of standardization process that I know of.
Our company supported development of MUA based annotations where DKIM
and the MTA IP addresses are used to qualify which messages receive
annotations. Although some may expect the Authentication-Results
header to be prefixed subsequent to the prefixing of the Received
header, there is no assurance that is would be a safe assumption.
There is not mandate in the draft, other than as a suggestive
example. In addition, there is no assurance that the IP address of
the SMTP client IP address is included within the Received header, and
that there are not subsequent down stream MTA that prefix the
Authentication-Results within the administrative domain.
Standardizing the IP address format within the Authentication-Results
header whenever path registration applied would be very helpful in
assuring there is less chance of some ISP doing something in an
unexpected fashion and that the very much needed reputation checks can
be assured by the MUA adding the annotation. After all, various
verification processes might be staged where path registration checks
could be done down stream based upon information known only by the
downstream MTA.
The only way that one can ensure that the _correct_ IP address is used
to inquire about reputation is to include this _absolutely_ essential
piece of information within the Authentication-Results header. Not
adding this information seriously reduces safety and security. Those
applying path registration checks MUST have already determined the IP
address seen at the Border MTA. There is no assurance that the border
MTA has applied this header, since it may have been based upon
privately confirmed information where there is no simple way to
identify the Received header added at the border.
Clearly this may not have been an issue when one controls these
factors within a homogenous infrastructure. Things being done by
Firefox or Thunderbird, or other types of plugins will not enjoy
having a homogenous infrastructure where the relative position and
format of the Received header may be unknown.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html