[Mimedefang] Best method of dealing with automatic - propagationvirus mails

[Kris Deugau]

Edward Wildgoose (and others) wrote:
[A number of interesting points of view regarding virus messages]

Hokay, time for my $0.02CDN.

I work for a small ISP, ~1600 dialup customers.  We currently run our
core services on Novell, but we're slowly migrating to Linux.  Our main
server hands off outbound email to a Linux box with MIMEDefang and an AV
package- but delivers mail locally for our users.  The outbound relay
server is also hosting added-value spam/virus filtering service for
local email.

Current policy is to:
1) Drop the virus part of the message.  No point in passing on 100-200K
of virus, or (as a previous "solution" did) 200K worth of blank spaces. 
(The claim from the AV vendor was that some MTAs would not like having
the message size altered in mid-process- one reason we dropped the
direct milter interface to that package, and now buffer its antivirus
scanner with MIMEDefang.)

2) Notify the (envelope) sender.  I agree that it's pretty useless to
send such a message to someone in the case of a virus like Bugbear,
which selects a random address to do its dirty work instead of the
users' "real" address.  But what about the viruses that *don't* forge
the sender address?

3) Replace the virus (or virus part;  this doesn't seem to be
consistent) with a warning, and pass the message on to the person who
might have been infected otherwise.

Our reasoning is as follows:
a) Notify the envelope sender, because we can't tie in our RADIUS logs
to see who's on that IP when the message is sent- and we (I) don't have
*time* to do it manually- even with a bit of script assistance the next
day.
I'd like to change this, but I have to convert the RADIUS server over to
Linux for that kind of access.  In progress (slow).
b) Notify the recipient, in case of (for instance) Word macro viruses. 
Just in case the email *was* legit.

Edward Wildgoose wrote:
> The point being that the "smart MX" is the hub and the first point of
> contact for most infected desktop machines.  If you could put even
> minimal virus blocking on a majority of Smart SMTP relays (and I kind
> of used the phrase "Large ISP", but really I meant the big hubs that
> most desktop users drop their mail into), then I suspect that you would
> eliminate a lot of problems at source.

Yep;  if the virus can't get off of the machine it infected, it can't
spread very quickly.

Of course there are other methods of spreading...  but email is by far
the worst.

>  It is *likely* to be very easy for the owner of the Smart Relay
> machine to know who is virus infected because they are probably the ISP
> for the person in question and can tie accounting records together,
> yada yada

Unless it's a system like ours, where we *don't* have easy realtime
access to our RADIUS logs.  (The server effectively doesn't *write* the
logfile until it's done that day's records.)  (Yes, ugh.  We're working
on changing that.)

> The really crunch is that many admins are actually on shaky legal
> ground to simply drop email.  Clearly you can't reliably inform the
> sender, and the recipient is more and more likely to be uninterested in
> knowing about a virus.

Even in a few cases where we have been able to manually identify whose
computer is infected, there have been a few idiots who, after REPEATED
warnings, phone calls, and email bounces, *STILL* haven't got the
message that they have a Problem, and they have to take some action to
fix it.

The final warning in those few cases has been that we *will* discard
their outbound email until they clean up their system.  Due to the setup
of our servers, it still leaves most of the rest of our users open to
attack;  we don't currently scan *everything* for viruses- "just" email
outbound from our system to others.  (~1.2G per week.)

>  However, lets suppose the world evolves again (and it will) and
> virus's start to transit in document files again (deliberately sent by
> user).  Now we are back to my "big CEO" example who will be annoyed
> that your mail server is quietly dropping his email without telling
> ANYONE!

In a corporate environment, this sort of thing would be *much* easier to
track.  Every desktop has an IP on the LAN, and messages can be
identified much more quickly.  Not having to support dialup users'
problems would give me time to do some of the manual digging required as
well...

> So emotionally I would prefer a solution which doesn't create an email
> blackhole.  To me at least the "reject" is the better of two evils (and
> personally I think the only other option is accept the mail, "bin it"
> and warn the recipient)

I would happily set things up that way;  but that would involve getting
~1600 dialup users to change their outgoing mail server settings.

Do you know how hard it is to get some of those people to enter things
correctly in the first place?

-kgd
WebHart Everything-Support, Mail Administrator, Systems Administrator,
and most of the other related hats.
-- 
Money is overrated.