North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: antivirus in smtp, good or bad?

  • From: Daniel Senie
  • Date: Tue Feb 03 11:37:48 2004

At 10:13 AM 2/3/2004, Joe Maimon wrote:



Daniel Senie wrote:

At 08:58 AM 2/3/2004, you wrote:
<snip>

Why must systems accept mail that's virus laden or otherwise not desired at a site?

The "bounce" you refer to invariably ends up going to the wrong person(s), so that's an exceptionally BAD idea. Many viruses (most of the recent ones) forge the sender information. So either accepting and silently dropping, or rejecting the SMTP session with a 55x are the only viable choices.
What you are saying is that every mailhost on the Internet should run up to date and efficient virus scanning? Pattern matching and header filtering? Should the executable attachmant become outlawed on the Internet? Recognize when a "to be bounced email" is a spoof and discard the DSN?
I'm saying, if you are going to run a virus scanner on your mail server, then either have it reject at the SMTP level or drop the messages on the floor. Accepting the email and then boucing it to someone who didn't send it further propagates the virus' annoyance level to otherwise unaffected people.

So no, I'm not advocating callbacks, and I'm not indicating there's any problem with authorized relays (secondary MX's, etc.). I'm just saying if you're going to have your mail server originate email messages in response to messages being dropped (for virus scanning, for example) it would be REALLY nice if they went to the originator of the message. If you can't determine the originator, then either drop the message, or don't accept it into your server.

Note that I never said you had to have virus scanning in your mail servers. There's no requirement for that. If you want to offer that service to your customers, that's your choice. If you don't want to, that's your choice too. If you do decide to offer the service, please do so in a responsible manner that does not further increase useless Internet traffic.