On Thu, Feb 12, 2004 at 02:18:05PM -0500, Keith Moore wrote:
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
message.
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.
Yes, the MTA would not know upfront whether it is a mail with virus, and
it would need to receive all of the mail to find out whether it is.
I think we agree on that. Whether it then is advisable to do that can be
discussed, my opinion is that we should recommend this. As far as I can
see the bandwidth consumed with email is quite low, compared to other
major services like ftp and http, that most sites will also be doing
(at least http). So bandwidth is not a major problem, at least not for
companies and organizations also running web services. For the personal
user, over modem connections, I think most of these are using some
mailbox service from their ISP, they use it via some IMPA service, and
then the ISP should do the virus scanning fro them, which many do.
So considerations for modem users are less relevant. Then there are the
private ADSL users (like me) that have their own Linux box running with
their own MTA (I have postfix here and I have a fixed IP for my 256 kbit
ADSL, but I mostly get my email via an IMAP service) - I think with the
current load of vira, which is high my bandwidth would not really be
affected, still.
Then the CPU cycles to handle virus inspection may be a problem.
I am not sure how much this would take, but on my oudated 1 GHz box,
it is not much. Then, I mostly look for attachments with specific file
name extensions, and then some specific lines for bogus error mail, so I
may not do it properly; and genuine virus checkers may use many more cpu
cycles.
My point is that receiving the full email and do virus check before
receipient checks, is not "just for finding out" whether there was a
virus, but to generate meaningful error messages on the receipient,
avoiding the bogus error messages. Better have my machine do that check
than me or other humans wading thru the vast amount of bogus email
errors in their inbox. It is a trade of bandwidth and cpu cycles for human
time.
And actually, using your bandwidth to receive the virus, for possible
discard, may even *reduce* the bandwidth use on the internet overall, and
eventually also for yourself. My analysis:
1. What happens if you reject the email on grounds of bad receipient?
The infector then just goes on to the next potential victim in his list.
Net result: the bandwidth consumed by sending virus on the internet total stays
the
same. And the infector will get back to you eventually, so your specific
bandwidth will possibly not be reducsd much by this, it would probably
get reduced by your skill in handling this compared to the average
performance of the internet.
2. If you read the virus and just discard it, you will reduce the
traffic of error messages - as you do not issue one. Some of this
traffic goes directly to the infector, but some goes to those that has
got it somehow, and is relaying it, and there some real humans are
saved from receiving bogus email - email that is not currently handled
with antivirus nor antispam software.
3. If you keep the infector busy with sending you stuff that you will
discard, then he cannot do other evil things at the same time.
That would probably reduce number of infected sites, and thus the amount
of infectors.
Net result: a reduction overall of the bandwidth used.
Probably som more use of cpu, but then network bandwidth is a more
precious ressource than the CPU, IMHO.
BTW, how does the virus propagate via non-infected systems?
One should think that just rejecting based on reciepient error would
go to the infector and stay there, but maybe the infector then relays
this error message to the purged sender? Or is it open relays that are
being used? (good we have RBL services that tell which machines are
openr:-( And then relayed to machines that do not use these RBL
services?
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 am not sure either, but would like to try it out.
Ie build my own RBL service. I am looking at the spamikaze
software for this.
I do think that a means of reliably identifying messages
that should never send mail can help reduce virus propagation.
That is another way to address the problem, and the methods are not
mutually exclusive, so we could do both. BTW, I did not intend to advocate
specific
ways of doing RBL in an RFC on best practices to avoid bogus error mail,
which is the subject we are discussing here.
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
question.
Yes, and in these days we are under constant virus attacks.
I do not expect the world to be more friendly in the future, it is
a war between the good and the evil. My impression is that currently
it is tolerable, and if the good people do things a little better,
like collectively just ignoring virus mail, the world can become an even
better place to live in.
--
He not busy being born, is busy dying. - Bob Dylan
I like that citation:-)
Keld