Isn't spam a Security Problem? (was Re: How is SPF different from RMX?)

On Aug 1, 2004, at 23:25, Dean Anderson wrote:
> Ok. Lets take a likely scenario:  There are roughly 30000 ISPs in the
> world. Lets suppose that either for good business or for anti-trust
> requirements, they all have to all allow their customers to outsource
> parts of their email system to the other ISPs.  So, each ISP has to allow
> the servers for each other ISP to send "from:" its domain.
>
> How well does that work?  Every ISP that is "trusted" can forge mail for
> the other ISPs. That doesn't really solve any problem at all.  I'll
> neglect the impracticality of maintaining the records for each server for
> each of those 30,000 ISPs, and the problem of distributing and updating
> that database. (Hosts.txt we missed you, or maybe we make root servers
> service a special zone of the ISPs mailservers, or maybe we make the root
> server operators operate a parallel set of servers for this zone)
>
> Even if you trust no other ISPs, all users at that ISP can still be able
> to forge mail from other users at that ISP.  That doesn't really solve any
> problem either.

Folks,

I'm a newbie lurker here so take my comments with a grain of salt.

Since Mr. Anderson uses the word trust above, he has entered the realm of security considerations.

It seems to me that spam is a security problem. The very first step in security is identification. SPF/SenderID looks like it implements the very stable three party security pattern. The sender is possibly a valid sender. The receiver does not know who the sender is or if they are authorized to send mail. Therefore, with SPF/SenderID, the receiver can ask a possibly independent IP address for another piece of evidence that identifies the sender IP as authorized to send mail for a domain. Like all good security, this is just one of the many mechanisms that both the sender and receiver will use to ensure valid transmissions. Other mechanisms, such as SSL/TLS or DomainKeys or S/MIME or PGP, will also help establish identification. SPF/SenderID, by helping defend brand identity, also helps stop something with financial consequences - phishing. 

The debate here seems to center around the cost/benefit ratio. Those of us who know that we cannot depend upon the authorities to defend our brand and reputation and must do it ourselves want to start enhancing the SMTP protocols to allow this to happen. Those of us who have built businesses that exploit current design features of SMTP that are at risk due to these changes understandably object to these changes. This debate cannot be resolved using technical issues, the basis of traditional IETF decision making. These are business concerns. As such, we should probably focus upon enabling this capability and letting the market of ideas sort this out. If SPF/SenderID has business value, it will survive. If not, MTA authors will stop asking for SPF/SenderID records and the extension will die. Those vendors whose business has to change during this experiment, as have all of our businesses during the spam deluge, will bear, perhaps, an undue burden. They should speak up now and help minimize that burden.

SPF/SenderID does not end spam but it provides a useful tool for, those of us who care about our brand identity, to help minimize spam and improve email as a more trusted medium. As such, it appears to be a useful, simple addition to my email toolkit.

Andrew

____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)