DAU> Date: Wed, 4 Aug 2004 14:46:02 -0700 DAU> From: David A. Ulevitch
DAU> I don't think SPF is worthless [1] but it isn't a drop-in DAU> solution and the impact on infrastructure will be DAU> significant if it becomes widely adopted.
When an architecture is "maxed out", it's difficult to make significant improvents that are drop-in.
DAU> I think people will realize that if we're remodeling the DAU> boat that much we should have at least made sure we were DAU> fixing something in the process...
Indeed.
Hogging the TXT RR is a bit greedy. Assuming homogenous policy across a domain name is a stretch. Surely someone else noticed KRB5 and its interaction with DNS.
Running something DNS-based that requires simple parsing is hardly an earth-shattering change; it smells similar to DNSBLs, yes? Yet it's still somewhat controversial.
And then there's LDAP...
In a situation where widespread agreement is mandatory, and consensus is better, drastic changes are difficult. If all netop-related technologies required NANOG-L agreement, nothing would ever get done.
I'd like to see widespread adoption of authenticated SMTP, with per-user restrictions on sender address. Alas, that's more difficult than, say, SAV. Call me cynical, but I don't see anything like SMTP auth+restrict taking the world by storm in the near future.
No, SPF isn't perfect. I'm trying to decide if it's even "good". Are the benefits worth the effort? I'm hopeful, but time will tell. Time will tell, but I'm hopeful. At this point, I'm game to give it a shot.
Sender-ID is not SPF. Sender-ID ignores the RFC 2821 MAIL-FROM and thus does not stop the bounce technique. It does not stop the virus filter response. Sender-ID does not allow for accurate accreditation. Microsoft wants everyone to sign a mutual IPR where this can not be transfered. After all the problems, much with the excessive use of DNS TXT records, Sender-ID will not have changed the amount of abuse seen, but will raise the support required to help customers with their mail. -Doug