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
place.
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.