1. reports that the body contained virus
2. reports that the user is unknown
3. reports that the user's account has been closed.
4. reports that the user's mailbox is full.
I think we'd agree that #1 should not be sent to the "sender" of the
virus since it is so often forged.
But reports #2-4 are often useful, and they _should_ be detected
before the server has a chance to look at the content of the
reports 2-4 are very often useful! But these reports should not be
generated, if the mail in question was a virus (number 1).
but the SMTP server doesn't have any way of knowing that the mail was a
virus. and it shouldn't have to suck down the message just for the
purpose of finding out.
I can understand that some rbls are propagating errors.
I dont think that some rbls today builds their data on
spamassasin result, which one should that be?
RCC is one that is willing to accept mail blocked for other reasons -
though I don't see them explicitly soliciting mail identified by
I also have my reservations to whether a sensibe RBL for infected
machines can be built. How to eliminate machines that are not
infected, but propagates virus via some open email lists?
I don't think RBLs can ever eliminate all virus mail, or even most
of it. I do think that a means of reliably identifying messages
that should never send mail can help reduce virus propagation.
My analysis is that for a number of servers the CPU load stemming
from this kind of bogus mail is not a problem.
I'm not sure what you mean by "analysis" here.
Maybe "experience" is closer to what I mean, but I think that many MTA
systems have enough muscle to do some work to deliver better quality
of error responses.
yes, they do. in part this is because these days, they have to be designed
to handle a generous amount of extra load in order to not melt down due to
occasional viruses, spam, or DoS attacks. whether this is a desirable
thing, or whether it's something we can reasonably expect, is a different
He not busy being born, is busy dying. - Bob Dylan