On Dec 12, 2008, at 3:40 PM, Murray S. Kucherawy wrote:
Douglas Otis wrote:
No, iprev would not be a good solution. The reverse IP address
space is poorly maintained which causes resource limited
performance to be reduced by an order of magnitude while waiting
for the timeouts.
But iprev requires relaying of the IP address as part of its
reported output. So the header field would report:
Authentication-Results: <authserv-id>; iprev=<result>
policy.iprev=<ip-address>
You could, I suppose, use that to relay the IP address to an
internal MUA or filter in association with results from other
methods, but that isn't the intended use of iprev. That sort of
thing remains out-of-scope.
This is abusing the iprev method when reverse DNS is not examined.
There is no result that says "skipped" just to note the IP address.
It is also wrong to suggest that a domain found with either Sender-ID
or SPF is more stable. It remains conjecture whether a domain that
appears to have authorized the SMTP client had established
restrictions on the use of their identifier. This uncertainty occurs
due to the lack of consensus regarding the basic scope of the SPF
record, versus the scope defined by Sender-ID. While the IESG
recommends advice given in Sender-ID, there is a large segment of the
community that ignored this advice. As such, a domain's relationship
with the SMTP client is not assured.
When this header is used to establish message annotations, listing a
compromised system by IP address for an extended period offers a means
to help ensure annotations are withheld. Such a listing by the IP
address would be less disruptive than when done by the domain. When
done by the domain, all messages will be prevented. When done by the
IP address, only those from the listed compromised system are
affected. In addition, IP addresses that are dynamically assigned are
also often persistently listed as such, and are seldom used to send
email.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html