antivirus in smtp, good or bad?

Mailman List Mirror (Read Only)
1

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.

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?

Thoughts?

Steve

2

Stephen J. Wilcox [2/3/2004 7:28 PM] :

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.

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?

Don't bounce. Reject with 5xx during the SMTP transaction (immediately after the DATA stage). If you accept the mail and detect a virus later, trash it instead of generating a bounce.

If you don't want to set up antivirus, at least set up Exim (preferably with exiscan-acl) to reject mail with suspicious attachments.

You might want to try the exim-users list for some more on this.

3

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.

4

Stephen J. Wilcox [2/3/2004 7:28 PM] :

> 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.
>
> 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?

Don't bounce. Reject with 5xx during the SMTP transaction (immediately
after the DATA stage). If you accept the mail and detect a virus later,
trash it instead of generating a bounce.

Ok I just realised what I'm doing here, 550 is a permanent fail and at this
point as I am holding the mail on my server I should decide to return it to the
sender. This isnt actually whats filling my queue and actually the reason I have
some of these with 550 codes in the queue log is because they are bounces which
means we handle them differently to normal mails and dont immediately fail them.

I'd mixed permanent and temporary, but thanks to rfc821 I've resolved my
confusion!

Steve

5

Stephen J. Wilcox [2/3/2004 8:13 PM] :

Ok I just realised what I'm doing here, 550 is a permanent fail and at this point as I am holding the mail on my server I should decide to return it to the sender. This isnt actually whats filling my queue and actually the reason I have some of these with 550 codes in the queue log is because they are bounces which means we handle them differently to normal mails and dont immediately fail them.

I'd mixed permanent and temporary, but thanks to rfc821 I've resolved my
confusion!

To clean out all the frozen mail ...

exim -bpru|grep frozen|awk {'print $3'}|xargs exim -Mr

6

Daniel Senie 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

7

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.

8

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.

9

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)

10

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.

11

Daniel Senie wrote:

Daniel Senie 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.

12

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

13

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

14

Stephen J. Wilcox 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.

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?

That's what I just wrote a patch into Postfix to do.... ( Projects at isux.com if anyone is interested, uses libclamav )

This is the only way I can see the virus laden mails should be dealt with - you certainly cannot return it to the sender, that is _most_ annoying, causes no end of users to call the support desk about being virus laden when they haven't actually been infected etc...

/ Mat

15

exim -bpru|grep frozen|awk {'print $3'}|xargs exim -Mr

Woops. missed a "m" at the end.

# exim -bpru|grep frozen|awk {'print $3'}|xargs exim -Mrm

       srs