Date: Sat, 23 Aug 2003 00:39:21 -0700
From: Robert LeBlanc
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
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. 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.
Robert LeBlanc
Renaissoft, Inc.
Date: Wed, 21 Jan 2004 01:36:52 -0800
From: Robert LeBlanc
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.