[Top] [All Lists]

Re: CBV systems - was Re: SMTP Extensions - proper peply code for disabled commands

2004-01-15 21:23:10

if widely adopted CBV will impair the reliability of the mail system by
causing delivery failures for legitimate messages in cases where
delivery would otherwise have been successful (i.e. if the return-path
field was invalid or not usable due to a configuration error or
temporary failure)

[Side note: I think the word legitimate does not play a role here as this
can happen in general.  The process has no information on whether the
transaction is legitimate, if it did, then we this CBV does not apply]

The (unstated) assumption is that the reliability of the mail system is defined in terms of how many legitimate messages were delivered vs. how many were sent. "Legitimate" is basically trying to encapsulate the idea that it's reasonable for the mail system to deliberately fail to deliver certain kinds of messages that have no legitimate purpose such as viruses and spam (at least, messages that can be reliably identified as spam).

However messages with invalid return-paths *can* have a legitimate purpose.

I fail to see where an invalid field would not be a problem in the first

An invalid return-path should have no effect at all when the message is able to be successfully delivered.

Ok, so what if a DSN was going to be sent? A normal SMTP queuing will occur.

If, once you've decided to bounce a message, you want to use CBV to decide whether to deliver a DSN, feel free, though I don't really see why you'd bother.

since CBV is easily circumvented by spammers, in the long term CBV does
no good - it only introduces overhead.

Well, IMO, this ideology applies to any solution, including those that may
be or not capable of being circumvented.  In other words, if a solution
works then it inevitably becomes overhead and redundancy.

So what's the point?

Good question. Some countermeasures are more easily circumvented than others, so it might make sense to deploy mechanisms that aren't easily circumvented. But a significant set of the spam countermeasures that people are deploying are pretty dubious anyway and probably shouldn't be deployed on a widespread basis. You also should consider how long it takes to deploy the countermeasure vs. how long it's likely to last - for something like CBV the spammers can circumvent it before you get it widely deployed. Finally, you should consider that it's much harder to get rid of features like CBV - even when they cause harm - than it is to deploy them.

Basically my concern is that poorly chosen countermeasures for spam and viruses are doing serious harm to the reliability of the mail system, so I want to discourage people from deploying them.

I think the important points in the debate is the exploitation of the
functional specification, not CBV. As long as the specs remain relaxed on client/sender validation, we are never going to solve anything and those
that do provide solutions will be accused of having "broken software."

Client/sender validation might well be a good idea. But we shouldn't confuse that with return-path validation.

<Prev in Thread] Current Thread [Next in Thread>