EVOLUTION-MANAGER

Edit File: README.policy-on-notifications

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.