Re: antivirus in smtp, good or bad?
At 08:58 AM 2/3/2004, you wrote:
Hi, When investigating our mail queue it seems we have quite a lot of mails which are stuck in transit...
Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they have antivirus service on that other account. So we get the mail, spool it and try to forward it but then we get a "550 Error: Suspected W32/MyDoom@MM virus" after DATA and our server freezes the mail.
Hmmm, well, we certainly kick back virus-laden stuff this way. The alternatives are: 1) kick it back during SMTP. 2) drop it on the floor. or, the third option, which is EXCEEDINGLY BROKEN, 3) send a bounce to the From: address in the email. Because of spoofed sender addresses, this then goes to the wrong person, freaks out innocent, non-infected people and raises everyone's support costs.
Surely this is an incorrect way to do this as there will be lots of similar MXs like ours backing this mail up? They should accept the mail and then bounce it?
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.
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? Will the concept of SMTP relaying die? Should the "bounce" become archaic? Perhaps SPF/RMX or the "mail from" smtp callbacks would help eliminate the spoofed sender problem? That could significantly raises the bar on MTA costs. Pattern matching on headers/attachments, while not strictly speaking 100% accurate (are emails with subject line of "Hi!" permitted on the Internet anymore?) are usualy performance sensitive. However there is the issue of manual intervention required to keep things up to date and as we know constant care and feeding of systems by admins is not cheap. Full blown signature based virus scanning, while automated, is NOT performance sensitive. Any sufficiently large MX will see a big hit if they perform that. In many cases the virus scanning rate will become the practical bottleneck. And we all know that SPF is on public trial now. We can watch and see. However, until you reject non-SPF email, it is unlikely to eliminate the spoofed email from hitting your spools. SMTP call backs? Wasnt there some b*tching about that here recently? Besides, even with signature based virus scanning, updates can occur slowly enough to allow a virus enough time to spread. Being that the case with many installed anti virus systems is updates maybe daily, it should not be a surprise how all these supposedely protected edge sites managed to get some infections. The alternative is to DOS the AV vendor. As I tell my customers, just delete the undeliverable notices if they do not apply to you. One day, Mozilla/Thunderbird or others might even run that though a "references a message I sent?" check for you. I do not think it is so simple. On a positive note, I believe that MTA's are standardizing the feature of seperate timeouts for DSN emails. That should lower spool sizes. Joe
Joe Maimon [2/3/2004 8:43 PM] :
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?
You are going to an extreme there I'm afraid ... I do agree that exaggeration helps stress a point, but ...
That could significantly raises the bar on MTA costs. Pattern matching on headers/attachments, while not strictly speaking 100% accurate (are emails with subject line of "Hi!" permitted on the Internet anymore?) are usualy performance sensitive.
Not always - limit it to two or three things like 1. Deny attachments with known "bad" extensions 2. Check for the patterns of the "flavor of the month" virus 3. Apply as many other rules as possible to reject the mail (checks for fake / spoofed helo etc) _before_ the mail gets to the virus scanning / pattern matching stage
However there is the issue of manual intervention required to keep things up to date and as we know constant care and feeding of systems by admins is not cheap.
Cron does help, and so do a few other things ...
Full blown signature based virus scanning, while automated, is NOT performance sensitive. Any sufficiently large MX will see a big hit if they perform that. In many cases the virus scanning rate will become the practical bottleneck.
It is a tradeoff. Is that the bottleneck, or is your systems and bandwidth being choked with virus mails, and double bounces because of undeliverable virus mail (say in the case of .forward users) the bottleneck?
As I tell my customers, just delete the undeliverable notices if they do not apply to you. One day, Mozilla/Thunderbird or others might even run that though a "references a message I sent?" check for you.
Mozilla / Thunderbird is nice, but using it to fetch your mail when dialed in long distance from a hotel room is not nice, when almost all the mail is viruses, virus notifications or virus mail that gets sent on, but with the malware removed from it so that your scanner can't catch the email. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Suresh Ramasubramanian wrote:
Joe Maimon [2/3/2004 8:43 PM] :
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?
You are going to an extreme there I'm afraid ... I do agree that exaggeration helps stress a point, but ...
<snip> What I was really trying to say is that it is far from a simple topic.
Joe Maimon [2/3/2004 9:19 PM] :
What I was really trying to say is that it is far from a simple topic.
yup, and if someone has a simple solution to this problem they are probably wrong (paraphrasing what [i think] Dave Crocker told me some months back when we met at ISPCON) -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
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.
Daniel Senie wrote:
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.
<snip> I agree. Rejecting with a 550 after DATA completes is becoming more common and acceptable. I think we have all agreed in previous threads that if a mail anti virus scanner does not know how to differentiate between a virus that spoofs the sender and one that doesnt, it should silently discard all virus infected email -- OR notify the local administrator/user at their choosing, but NOT bounce it.
I think we have all agreed in previous threads that if a mail anti virus scanner does not know how to differentiate between a virus that spoofs the sender and one that doesnt, it should silently discard all virus infected email -- OR notify the local administrator/user at their choosing, but NOT bounce it.
Since the notion not to bounce a "you mailed a virus" message back the sender is heard everywhere, I thought I'd mention this.... Our mail server generates an incredible amount of bounces because of user accounts either not existing or being over quota. The signature based virus scanner hooks in at the local delivery, so the mail spool isn't scanned for viruses. As a result many messages are returned intakt, including attached virus, to the fake 'From:' address..... The fun and games of an archaic, abused, defunct mail delivery system... Adi
At 06:16 AM 2/3/2004, Daniel Senie wrote:
Many viruses (most of the recent ones) forge the sender information.
It seems to me that this can be replaced with "Today's viruses almost invariably forge the sender information." and that it no longer makes any sense whatsoever to send a virus alert notice to the address indicated in the "from" header. Can anyone remember the last time they encountered a virus that *didn't* forge the sender information? IIRC, the last one I saw was an AnnaK virus, ~3 years ago. jc
participants (5)
-
Adi Linden -
Daniel Senie -
JC Dill -
Joe Maimon -
Suresh Ramasubramanian