On 10/30/09 1:05 PM, John R. Levine wrote:
I can't say, but I do know that many of us toss a whole lot of mail at EHLO,
some at MAIL FROM:<> and some at DATA. The idea I was thinking about was
whether it provides any value whatsoever to at least know that you are
authentically dealing with a legitimate source sooner, without having to send
even a whole header.
Well, there's STARTTLS. Again, it's there, I believe there's pretty broad
support, but it doesn't seem popular outside of some specialized financial
environments.
Also remember CSV which Dave and I concocted to allow sites to identify
the hosts that are supposed to be mail clients.
John, it was Dave Crocker, John Leslie, and myself, where I had
independently written a draft similar to Dave's.
It is really a shame too, as this approach would have helped establish a
name basis for a reputation scheme that could have been applied early in
the SMTP transaction. A reputation scheme based upon any authorization
that leave providers nameless would be wrong and inherently unfair.
The immediate forward reference to identify SMTP hostnames would have
been effective in mitigating much of the bot-net generated traffic
without any change to SMTP. Of course, retention of the SMTP client IP
address would help as well. Perhaps CSV might be how the IP
address/hostname gets added to the Authentication-Results header. :^)
Dealing with IPv6 will likely require reputations be based upon a domain
name rather than upon individual IP addresses. The remaining question
would be affirming SMTP hostnames. Reverse DNS invites long timeouts,
making this effort fairly expensive from a resource standpoint.
DKIM might help in identifying which SMTP clients are legitimate.
Allowing DKIM to "bless" other originating domains found within the
email transaction (via TPA-Labels) could help in spreading the trust
established. Perhaps the TPA-Label for a hostname could include a CVS
requirement flag or a couple of CIDR entries.
Maybe providers will stop avoiding naming their role the in issuing
email. I strongly believe autonomous authentication schemes for DKIM
can greatly increase the value of the service. When combined with CSV,
replay issues could be handled in manner compatible with third-party
re-mailers, such as mailing-lists.
Looking for the low-cost web of trust...
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html