Re: A new SMTP "3821" [Re: FTC stuff...........]
Dean Anderson <[email protected]>
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 8 Dec 2004, Chris Haynes wrote: > > On December 08, 2004 5:18 AM +00 "Dean Anderson" sent: > > > Err, no. SPF does make the blowback problem much worse. Other schemes > > create a few percent blowback. SPF enables 100% blowback. Thats much > > worse. > > I hesitate to (re-)enter this thread, and, once again, I'm trying to be fair and > understand the substantive basis for concerns.. > > It has been argued in SPF circles, that if you receive a message which the > (purported) sender's policy declares to be a hard failure (-), the message is > _proven_ to be a forgery, an unauthorised re-transmission, or whatever. > > Since the purported sender has repudiated the message, the argument goes, the > original SMTP 'contract' to "deliver or bounce" is null-and-void, The mailserver getting the rejection code and generating the bounce may not participate in the SPF "contract modification". One would also have to create a special 5xx code to indicate "reject, but don't bounce", and then upgrade all mailservers everywhere. And I suspect some people might not accept silent rejection in principle, and send bounces anyway. It is probably easier for the recipient mailer to receive but not deliver (silent discard) But silent discards are also particularly difficult to debug. And you wouldn't want to do this unless everyone on the planet had SPF records. > since whoever actually injected the message did so without the authority > of the domain they cited. Therefore it is acceptable to 'silently > discard' such messages, and not send bounces. It isn't necessarilly the case that SPF-rejected email is forged or unauthorized. It might just be the hosting company isn't allowing outsourcing of the domain. (or is doing "unreliable" name service to harm the other company and gain back the outsourced business). It would not be acceptable to silently discard these messages, since one would never know why the message wasn't received. Silent rejection seems to be a bad approach. And of course, SPF rejections might happen simply because the IP addresses of the authorized servers changed, but the TTLs on the SPF records haven't expired. This would be new blowback on otherwise good email. This could go for weeks or months after an IP address is changed. IP Addresses are frequently changed unexpectedly as a result of abusive blacklists that can't be taken to court. Since you can't sue anonymous blacklists like SPEWS, when they block legitimate business, the only alternative is to get a new IP address. This, of course, is unplanned. No doubt the abusive blacklist would appreciate the ability to create additional interference. That should probably be #14 on the list. > Do you have any sympathy with that reasoning, and would it change your view > about 100% blowback? Ignoring the just-described problems with silent rejection, silent rejection could reduce blowback, but it still requires replacement of all current mailserver software. That would take many years to achieve. In the meantime, there is 100% blowback. I note that recent documents from Comcast show that it would cost $58 million just to tell their users to change relays, at $9 per support call. Upgrading all the mailserver software on the planet must be fairly expensive. And it might never be really finished. And whatever system you put into place will still be abused, perhaps differently, but still abused just the same. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000