ietf-mxcomp
[Top] [All Lists]

Re: A new SMTP "3821" [Re: FTC stuff...........]

2004-12-08 17:43:18

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