On Tue, Jan 13, 2009 at 06:17:53PM +0000, David Wilson wrote:
If by "reject" you mean "give a 5xx response to the data from the SMTP
client, the problem with that is that, as previously discussed, the SMTP
client server may generate a DSN or similar which returns the infected
message. It does not know that the reason for non-delivery was the
suspect message content. You do. So the only safe responses are:
- discard the message (i.e. accept it over SMTP and then throw it away
with no further processing, apart from possible archiving).
- send a DSN or similar which suppresses return of content.
I've got serious problems with both of those.
In the first case, you're telling the sending server one thing and
doing another. I don't think that's a good idea on two levels:
at a philosophical level, this seems like a bad way to run an Internet.
At a practical level, doing so fails to alert the sending site that
they may have a problem. (Yes, I'm presuming that they're paying
attention to their own logs...or that they will be more inclined to
do so when they notice 86,000 5xx error messages in them.)
In the second case, generating DSNs is a bad idea in general [1],
but it's a REALLY bad idea as a response to spam/virus messages.
Look, I understand the motivation, and it's very noble, but it's
also pointless. A hypothetical virus relying on this method of
propagation will also have many other -- many other SIMPLER --
ways of delivering itself to the very same targets. The best that
anyone external can do is (a) don't propagate the problem further
(b) communicate via appropriate use of SMTP that there's a problem
and (c) don't make the problem worse or more complicated or more obscure.
---Rsk
[1] It's not that hard to engineer mail architectures -- including
distributed and multi-tier architectures -- that always reject and
never bounce. Yes, there are always edge cases to be dealt with,
but making them exceptions and not the rule makes it easier to
then minimize the occurence/duration of those exceptions.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg