Date: Sat, 23 Aug 2003 00:39:21 -0700
From: Robert LeBlanc <rjl@renaissoft.com>
Subject: Re: [AMaViS-user] All admins and other amavis users, listen up!
To: amavis-user@lists.sourceforge.net
Message-id: <5.1.1.6.2.20030822235747.02e41dc8@127.0.0.1>

At 11:45 2003/08/22, Peter Surda wrote:
>On Thu, Aug 21, 2003 at 02:00:05PM -0500, cdupree@csr.utexas.edu wrote:
> > On Thu, Aug 21, 2003 at 04:29:15PM +0200, Olivier Tharan wrote:
> > > >  People, I urge everyone here to switch off all sender notifications
> > > >  unconditionally. This is getting out of hand.
> > > I completely agree. While it becomes depressing for the admins to see
> > > such harm done with a single virus, the (l)users are panicked because
> > > they think they have caught a virus on their computer.
> > I completely disagree.  In this case it's probably useful.  But what if
> > you were sending me a legitimate mail and it had an infected attachment.
>Please show me ONE example from the real world where this actually happened.

When I first started using AMaViS (back in the days of amavis-perl-11), I 
used to think the idea of sending virus notifications to the sender was a 
really good one--a nice courtesy, and one that the sender would 
appreciate.  In theory, at least, it was possible for a virus to slap a 
copy of itself on to all outgoing e-mail as an attachment, such that the 
sender wasn't even aware this was happening.  The recipient would receive 
the legitimate e-mail, but with a mysterious attachment the sender was 
unaware of, and the fact that the mail itself was legitimate often 
encouraged the recipient to trust the attachment as well.

This moved from the realm of theory to the realm of practice back in 2000 
or so, when I recall a particular virus that did exactly this, targeting 
Outlook and Outlook Express users.  While I can't recall the name of the 
virus anymore, I can attest to the fact that I *have* encountered such a 
beast, and had a number of users posting to mailing lists and newsgroups, 
unwittingly spreading their viruses until they were ultimately told to 
cease and desist and get their systems fixed.  If these people were never 
told that they were spreading a virus, they'd have had no idea they were 
doing so.

That said, I haven't seen a virus like that in several years, possibly 
because those particular exploits in Outlook and Outlook Express have been 
patched and there are fewer vulnerable installations out there as a 
result.  These days we're facing a different breed of mass-mailer virus, 
and none of the current crop of threats is particularly well served by 
virus notifications.

By their very definition, these "mass-mailers" (the viruses that end in 
"@MM") get their sender and recipient lists from the victims' address 
books, so notifying the actual sender is all but impossible.  When these 
virus notification e-mails arrive, it's almost always in the mailbox of an 
innocent party, who then becomes needlessly confused or alarmed (or even 
indignant!).  After they're calmed down and told to disregard the notice, 
of course, they then program themselves to ignore every *other* virus 
notification mail they receive, effectively defeating the purpose of such 
things.

Worse, sending out automated virus notifications to all of these supposed 
senders effectively contributes to the problem by generating an exponential 
increase in the wasted bandwidth (since in many cases those virus 
notification e-mails bounce).   In the case of worms whose objective is to 
generate a denial-of-service effect, automated virus notifications only 
amplify their effectiveness.

Even more alarming is the fact that some of these virus notification 
systems try to be helpful by sending back the original (infected) mail to 
the supposed sender--complete with the virus attached!  When this ends up 
in the mailboxes of dozens or hundreds of innocent people instead, it puts 
them unnecessarily at risk of infection.  During the recent Sobig.f 
campaign, my wife (who is a journalist), received more than 400 copies of 
the virus--and *300* virus notification mails, no less than 100 of which 
contained more copies of the virus.  Interestingly, because of the way some 
of these mailers incorporated the virus into the body in their notification 
mail, a dozen or so copies slipped past amavisd-new and the battery of 
virus scanners running here.

The problem is significant enough that some RBLs are adding sites that send 
out automated virus notifications (e.g. blackholes.five-ten-sg.com, result 
127.0.0.10), so that others can block mail from these "offenders".  As 
people get fed up with notifications that they consider "useless" or 
"alarming", they come to view them as just another form of spam, and want 
it blocked like the rest.  All the best intentions in the world won't 
change that.

In the end, then, I find myself on the other side of things--I no longer 
send out automated notifications for viruses or spam, as I don't consider 
it appropriate these days.  Modern viruses and spam broadcasters use 
techniques that render such notification mail less than useless, and cause 
many more problems than they potentially solve.  While there's always a 
chance that a legitimate e-mail with an infected attachment could be 
winging its way to one of my users right now, that chance is vanishingly 
small compared to the harm I'd be causing by sending out automated virus 
notifications for every instance of every other virus we receive.

Do I think that AMaViS should ship with automated notification turned off 
by default?  Not necessarily.  What I *would* prefer to see, however, is 
more information provided to administrators about the consequences of using 
automated notifications (or not using them).  There are certainly 
trade-offs to be made, and providing inexperienced administrators with some 
advice on making this decision would be quite helpful, in my opinion.  A 
few paragraphs like the ones above, explaining the rationale for using or 
not using automated notifications, is all it would take, really.  Then let 
the administrator configure things in accordance to the needs and policies 
of his organization.

Robert LeBlanc
Renaissoft, Inc.




Date: Mon, 01 Sep 2003 17:18:15 -0700
From: Robert LeBlanc <rjl@renaissoft.com>
Subject: Re: [AMaViS-user] Using D_Discard to discard trapped emails
To: amavis-user@lists.sourceforge.net
Message-id: <5.1.1.6.2.20030901165615.01712880@127.0.0.1>

...
You'll get a few different answers from the various people on this list, as 
this is a somewhat controversial topic.  Basically there are three main 
points of view:

(1) The "lose no mail" camp believes that a mailer should never discard 
mail without notifying the sender that the mail was not delivered (and of 
course if you do notify the sender, the mail was actually "rejected", not 
"discarded").  If you discard mail, you're effectively creating a "mail 
sink"--a black hole into which mail vanishes, to be lost forever.  The 
integrity of the Internet mail system would be questionable if this sort of 
practice were widespread and mail was being lost on a regular basis.  When 
you send mail to someone and that user's mailbox is full, or his mail 
server is down (hopefully temporarily), you expect to receive a 
notification to tell you your mail wasn't delivered; without this notice, 
you'd (wrongly) believe your mail got to its destination.

(2) The "acceptable losses" camp generally started out in the "lose no 
mail" camp, but eventually got frustrated with all the bounces (and bounces 
from bounces) flooding their mailboxes as a result of automated mechanisms 
like virus/spam/banned/header alerts.  These folks have come to the 
conclusion that while it's noble and virtuous to never discard mail, it's 
not a practical solution these days.  The volume of "noise" polluting 
mailboxes and wasting bandwidth across the Internet makes a strong argument 
for discarding mail, rather than contributing to the problem by sending out 
more noise.  Sure, a few legitimate mail items are likely to get lost this 
way, but these are considered "acceptable losses" when weighed against the 
volume of noise being filtered.

(3) The "discard safely" camp (to which I now subscribe) believes that 
discarding mail is acceptable, but only as long as the mail itself is not 
lost.  The sender doesn't need to be notified that the mail was not 
delivered, *if* the mail is quarantined in a manner that allows the 
recipient to review it.  In a sense, then, the mail *was* delivered, just 
to an alternate mailbox or quarantine area.  The key addition, here, is a 
quarantine management facility that lets users review the quarantined items 
and rescue any legitimate items that may have been trapped there.  While 
amavisd-new provides the quarantining mechanisms, it lacks management 
facilities.  <another shameless plug>If you need something like this, you 
can try an add-on package like Maia Mailguard 0.9.5a 
(http://www.renaissoft.com/projects/maia), which provides per-user control 
for amavisd-new, per-user quarantine management, user administration 
functions, and stats-gathering/graphing.</another shameless plug>

Robert LeBlanc
Renaissoft, Inc.




Date: Wed, 21 Jan 2004 01:36:52 -0800
From: Robert LeBlanc <rjl@renaissoft.com>
Subject: Re: [AMaViS-user] W32/Bagle-A
To: amavis-user@lists.sourceforge.net
Message-id: <6.0.1.1.2.20040121011109.04e23678@127.0.0.1>

[...]
>>... Since amavis is smart enough not to include the virus in the DSN,
>>the notice the sender receives is at least "clean".
>
>But the wrong person gets it.
>
>At least when one of my clients tries sending email through my SMTP 
>server, they'll get the rejection notice immediately. The mail won't go 
>anywhere, they won't get any bounce, they just get a message from their 
>MUA saying that the message was rejected.

[Robert LeBlanc talking about Postfix and dual-sendmail-setup,
 not about the Sendmail milter setup (Mark)]

This assumes that your MTA "handles the rejection [from amavis] properly", 
of course.  MTAs know nothing about viruses (or spam for that matter), so 
they can't do the rejection themselves on this basis.  When clients send 
mail through your MTA, your MTA relays that mail to amavis, which does the 
content-checking.  If amavis finds a virus and uses D_REJECT, the 
responsibility falls back to your MTA to decide what to do.  When MTAs 
receive a permanent failure SMTP error (i.e. 5xx), they try to be helpful 
by generating DSNs that include the full original mail, to send back to the 
sender, explaining the rejection.  Your client would then get the virus 
sent back to him in the DSN.

This is harmless (quite helpful, actually) when the sender happens to have 
an old-style virus, of course, but with the "viruses that fake sender 
addresses" this is a distribution method.  Consider that your user has one 
of these viruses on his machine and it starts spewing out copies of itself 
through your mail server, all with fake sender addresses.  When your MTA 
sends out its DSNs to those fake addresses, those DSNs will contain the virus.

If you'd used D_BOUNCE instead, the DSNs would be issued by amavis (which 
is virus-aware) rather than your MTA (which isn't), so the mail going to 
those fake senders would be virus-free.

My point is that your idea of "reject at the MTA" doesn't work as such, 
because the MTA does not have a virus scanner embedded in its own 
logic.  The rejection takes place at the content-filtering stage (i.e. 
amavis), so the rejection is handed to the MTA by amavis, rather than from 
your MTA to the client.  Your MTA will still produce a DSN and helpfully 
send back the original mail--that's what SMTP dictates that it *must* 
do.  You're better off using D_BOUNCE and letting amavis issue its own DSN, 
so that at least you won't be spreading the virus itself any 
further.  *Both* methods generate spam-by-proxy, but one of them also 
spreads viruses.

The closest thing to an "ideal" solution, in my (admittedly biased) 
opinion, is what I refer to as the "discard safely" policy--D_DISCARD items 
like these after quarantining them--provided that you have a quarantine 
management system (e.g. Maia Mailguard) that lets users access these 
quarantined items.  No DSNs get sent out, as the mail is effectively 
"accepted" (into quarantine), and the local recipients have access to this 
special mailbox to retrieve anything they want to keep, so there's no 
*need* for a DSN--the mail was, for all intents and purposes, successfully 
"delivered" to the recipients.


Robert LeBlanc
Renaissoft, Inc. 
