> >> It is returning a "550" error code during the SMTP transaction, rather
>than sending a virus notification. In that case, the remote mailserver is
>responsible for determining the format of the bounce message. <<
>
>Scott - do I understand you correctly? IMail AntiVirus is rejecting
>infected emails DURING the SMTP communication? In other words, it doesn't
>first get accepted (as is the case with Declude)?
That is correct. This method has advantages and disadvantages.
>If that's the case, then I see this as a major advantage of Imail's
>AntiVirus solution.
Well, one serious disadvantage is that it spreads viruses! That's why I
would recommend anyone using IMail AntiVirus set it up to accept the E-mail
and send out notifications.
Although in the majority of cases, rejecting the message would not spread
the virus (it would go to someone who already has the virus, someone who
already received a copy of the virus, or wouldn't be fully transmitted), in
some cases it would cause the virus to spread further.
>I wouldn't HAVE to worry about the extra message volume
>caused by sending out virus notifications (possibly to faked addresses) and
>then deal with the bounce messages because they WERE faked.
But, you have no control over what happens. If someone using IMail sends
you a virus, they will get back an "Unknown user" message, with no clue
that they sent a virus. And, in the case of the Klez virus, the bounce
could go to the wrong person. Remember, Declude Virus does have a way of
handling the forged addresses.
And, while you don't have all that extra message volume, you do have the
volume of all those viruses. The notifications amount to about 5% or so of
the volume of the viruses themselves. The viruses still have to be
received in order for any AV program to detect the virus.
Another drawback is that if scanning gets delayed for some reason, multiple
copies of the virus may get sent (after the remote mailserver sends the
"I'm done sending the message" command, and before your mailserver responds
with "OK" -- during with this virus scanning takes place -- if the
connection is broken or times out, the virus will get re-sent).
>Instead the SENDING mail server would know that the mail was never
>ACCEPTED and that
>server is much better suited to notify the TRUE sender.
Not so. Here are the Received: headers from a recent copy of Klez we received:
Received: from smtp-01-003.root-mail.com [64.7.192.136] by declude.com with
ESMTP
(SMTPD32-7.06) id ACC82AA50374; Sun, 30 Jun 2002 07:34:32 -0400
Received: from Mpwjz (eva-85-199.bvunet.net [216.184.85.199] (may be forged))
by smtp-01-003.root-mail.com (8.12.3/8.12.3) with SMTP id
g5UBUkgc015953
for <[EMAIL PROTECTED]>; Sun, 30 Jun 2002 04:30:47 -0700
Klez sent it to 64.7.192.136, which then sent it to us. If IMail had
bounced the message, 64.7.192.136 would have sent the bounce message to the
return address, which was forged. So no benefit there (a drawback
actually, as Declude would prevent that notification from getting sent,
knowing that the address was forged).
The most common method of virus scanning involves receiving the E-mail
first, then scanning it (the way Declude does it). IMail AntiVirus can
scan the E-mail "mid-stream". Both have advantages and disadvantages. My
preference is receiving the E-mail first (although I am admittedly biased).
-Scott
---
Declude: Anti-virus, Anti-spam and Anti-hijacking solutions for
IMail. http://www.declude.com
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit the Knowledge Base for answers to frequently asked
questions: http://www.ipswitch.com/support/IMail/
