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
