An Intermediate MTA can easily perform path registration checks when
the border MTAs are known by the Intermediate MTA. This data would
only be known by the Intermediate MTA adding the Authentication-
Results header, and not to plugin vendors adding email annotations.
We have worked with these vendors that offer such MUA and browser
plugins that check the IP address of the MTA sending the message
before adding their annotations. This is done unseen in the background.
It is common to find abuse occurring due to policy exceptions that are
granted less scrupulous sales departments. This email is often
isolated to "advertising" servers. Abuse also often occurs when one
out of many MTAs becomes compromised. Those providing enhanced
information to recipients can better protect their clients and cause
less disruption to email when these providers are allowed to block
only the affected SMTP servers identified by their IP address, rather
than blocking an entire domain offering authorizations.
As was stated several times before, those providing reputation
services MUST ensure only negative reputation is assigned to verified
identifiers. In the case of the SMTP client IP address, this means
being able to identify the IP address seen at the border, and to
ensure there is no evidence of BGP spoofing. By carefully monitoring
the IP address space, a significant level of additional protection can
be afford recipients. As was stated for Sender-ID, whether the
sender has assured PRAs are restricted by outbound MTAs is unknown,
and therefore it is not safe to assume it was. An error in this
assumption, and any negative reputations that might occur which did
not originate from the authorizing domain, will be injurious to this
domain. It is much safer to depend upon the IP address of the SMTP
client in these cases instead. By all means, those offering services
that are likely to be phished should be using DKIM instead.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html