"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "amavisd-new-2.6.1/README_FILES/README.policy-on-notifications" of archive amavisd-new-2.6.1.tar.gz:

    1 Date: Sat, 23 Aug 2003 00:39:21 -0700
    2 From: Robert LeBlanc <rjl@renaissoft.com>
    3 Subject: Re: [AMaViS-user] All admins and other amavis users, listen up!
    4 To: amavis-user@lists.sourceforge.net
    5 Message-id: <5.1.1.6.2.20030822235747.02e41dc8@127.0.0.1>
    6 
    7 At 11:45 2003/08/22, Peter Surda wrote:
    8 >On Thu, Aug 21, 2003 at 02:00:05PM -0500, cdupree@csr.utexas.edu wrote:
    9 > > On Thu, Aug 21, 2003 at 04:29:15PM +0200, Olivier Tharan wrote:
   10 > > > >  People, I urge everyone here to switch off all sender notifications
   11 > > > >  unconditionally. This is getting out of hand.
   12 > > > I completely agree. While it becomes depressing for the admins to see
   13 > > > such harm done with a single virus, the (l)users are panicked because
   14 > > > they think they have caught a virus on their computer.
   15 > > I completely disagree.  In this case it's probably useful.  But what if
   16 > > you were sending me a legitimate mail and it had an infected attachment.
   17 >Please show me ONE example from the real world where this actually happened.
   18 
   19 When I first started using AMaViS (back in the days of amavis-perl-11), I
   20 used to think the idea of sending virus notifications to the sender was a
   21 really good one--a nice courtesy, and one that the sender would
   22 appreciate.  In theory, at least, it was possible for a virus to slap a
   23 copy of itself on to all outgoing e-mail as an attachment, such that the
   24 sender wasn't even aware this was happening.  The recipient would receive
   25 the legitimate e-mail, but with a mysterious attachment the sender was
   26 unaware of, and the fact that the mail itself was legitimate often
   27 encouraged the recipient to trust the attachment as well.
   28 
   29 This moved from the realm of theory to the realm of practice back in 2000
   30 or so, when I recall a particular virus that did exactly this, targeting
   31 Outlook and Outlook Express users.  While I can't recall the name of the
   32 virus anymore, I can attest to the fact that I *have* encountered such a
   33 beast, and had a number of users posting to mailing lists and newsgroups,
   34 unwittingly spreading their viruses until they were ultimately told to
   35 cease and desist and get their systems fixed.  If these people were never
   36 told that they were spreading a virus, they'd have had no idea they were
   37 doing so.
   38 
   39 That said, I haven't seen a virus like that in several years, possibly
   40 because those particular exploits in Outlook and Outlook Express have been
   41 patched and there are fewer vulnerable installations out there as a
   42 result.  These days we're facing a different breed of mass-mailer virus,
   43 and none of the current crop of threats is particularly well served by
   44 virus notifications.
   45 
   46 By their very definition, these "mass-mailers" (the viruses that end in
   47 "@MM") get their sender and recipient lists from the victims' address
   48 books, so notifying the actual sender is all but impossible.  When these
   49 virus notification e-mails arrive, it's almost always in the mailbox of an
   50 innocent party, who then becomes needlessly confused or alarmed (or even
   51 indignant!).  After they're calmed down and told to disregard the notice,
   52 of course, they then program themselves to ignore every *other* virus
   53 notification mail they receive, effectively defeating the purpose of such
   54 things.
   55 
   56 Worse, sending out automated virus notifications to all of these supposed
   57 senders effectively contributes to the problem by generating an exponential
   58 increase in the wasted bandwidth (since in many cases those virus
   59 notification e-mails bounce).   In the case of worms whose objective is to
   60 generate a denial-of-service effect, automated virus notifications only
   61 amplify their effectiveness.
   62 
   63 Even more alarming is the fact that some of these virus notification
   64 systems try to be helpful by sending back the original (infected) mail to
   65 the supposed sender--complete with the virus attached!  When this ends up
   66 in the mailboxes of dozens or hundreds of innocent people instead, it puts
   67 them unnecessarily at risk of infection.  During the recent Sobig.f
   68 campaign, my wife (who is a journalist), received more than 400 copies of
   69 the virus--and *300* virus notification mails, no less than 100 of which
   70 contained more copies of the virus.  Interestingly, because of the way some
   71 of these mailers incorporated the virus into the body in their notification
   72 mail, a dozen or so copies slipped past amavisd-new and the battery of
   73 virus scanners running here.
   74 
   75 The problem is significant enough that some RBLs are adding sites that send
   76 out automated virus notifications (e.g. blackholes.five-ten-sg.com, result
   77 127.0.0.10), so that others can block mail from these "offenders".  As
   78 people get fed up with notifications that they consider "useless" or
   79 "alarming", they come to view them as just another form of spam, and want
   80 it blocked like the rest.  All the best intentions in the world won't
   81 change that.
   82 
   83 In the end, then, I find myself on the other side of things--I no longer
   84 send out automated notifications for viruses or spam, as I don't consider
   85 it appropriate these days.  Modern viruses and spam broadcasters use
   86 techniques that render such notification mail less than useless, and cause
   87 many more problems than they potentially solve.  While there's always a
   88 chance that a legitimate e-mail with an infected attachment could be
   89 winging its way to one of my users right now, that chance is vanishingly
   90 small compared to the harm I'd be causing by sending out automated virus
   91 notifications for every instance of every other virus we receive.
   92 
   93 Do I think that AMaViS should ship with automated notification turned off
   94 by default?  Not necessarily.  What I *would* prefer to see, however, is
   95 more information provided to administrators about the consequences of using
   96 automated notifications (or not using them).  There are certainly
   97 trade-offs to be made, and providing inexperienced administrators with some
   98 advice on making this decision would be quite helpful, in my opinion.  A
   99 few paragraphs like the ones above, explaining the rationale for using or
  100 not using automated notifications, is all it would take, really.  Then let
  101 the administrator configure things in accordance to the needs and policies
  102 of his organization.
  103 
  104 Robert LeBlanc
  105 Renaissoft, Inc.
  106 
  107 
  108 
  109 
  110 Date: Mon, 01 Sep 2003 17:18:15 -0700
  111 From: Robert LeBlanc <rjl@renaissoft.com>
  112 Subject: Re: [AMaViS-user] Using D_Discard to discard trapped emails
  113 To: amavis-user@lists.sourceforge.net
  114 Message-id: <5.1.1.6.2.20030901165615.01712880@127.0.0.1>
  115 
  116 ...
  117 You'll get a few different answers from the various people on this list, as
  118 this is a somewhat controversial topic.  Basically there are three main
  119 points of view:
  120 
  121 (1) The "lose no mail" camp believes that a mailer should never discard
  122 mail without notifying the sender that the mail was not delivered (and of
  123 course if you do notify the sender, the mail was actually "rejected", not
  124 "discarded").  If you discard mail, you're effectively creating a "mail
  125 sink"--a black hole into which mail vanishes, to be lost forever.  The
  126 integrity of the Internet mail system would be questionable if this sort of
  127 practice were widespread and mail was being lost on a regular basis.  When
  128 you send mail to someone and that user's mailbox is full, or his mail
  129 server is down (hopefully temporarily), you expect to receive a
  130 notification to tell you your mail wasn't delivered; without this notice,
  131 you'd (wrongly) believe your mail got to its destination.
  132 
  133 (2) The "acceptable losses" camp generally started out in the "lose no
  134 mail" camp, but eventually got frustrated with all the bounces (and bounces
  135 from bounces) flooding their mailboxes as a result of automated mechanisms
  136 like virus/spam/banned/header alerts.  These folks have come to the
  137 conclusion that while it's noble and virtuous to never discard mail, it's
  138 not a practical solution these days.  The volume of "noise" polluting
  139 mailboxes and wasting bandwidth across the Internet makes a strong argument
  140 for discarding mail, rather than contributing to the problem by sending out
  141 more noise.  Sure, a few legitimate mail items are likely to get lost this
  142 way, but these are considered "acceptable losses" when weighed against the
  143 volume of noise being filtered.
  144 
  145 (3) The "discard safely" camp (to which I now subscribe) believes that
  146 discarding mail is acceptable, but only as long as the mail itself is not
  147 lost.  The sender doesn't need to be notified that the mail was not
  148 delivered, *if* the mail is quarantined in a manner that allows the
  149 recipient to review it.  In a sense, then, the mail *was* delivered, just
  150 to an alternate mailbox or quarantine area.  The key addition, here, is a
  151 quarantine management facility that lets users review the quarantined items
  152 and rescue any legitimate items that may have been trapped there.  While
  153 amavisd-new provides the quarantining mechanisms, it lacks management
  154 facilities.  <another shameless plug>If you need something like this, you
  155 can try an add-on package like Maia Mailguard 0.9.5a
  156 (http://www.renaissoft.com/projects/maia), which provides per-user control
  157 for amavisd-new, per-user quarantine management, user administration
  158 functions, and stats-gathering/graphing.</another shameless plug>
  159 
  160 Robert LeBlanc
  161 Renaissoft, Inc.
  162 
  163 
  164 
  165 
  166 Date: Wed, 21 Jan 2004 01:36:52 -0800
  167 From: Robert LeBlanc <rjl@renaissoft.com>
  168 Subject: Re: [AMaViS-user] W32/Bagle-A
  169 To: amavis-user@lists.sourceforge.net
  170 Message-id: <6.0.1.1.2.20040121011109.04e23678@127.0.0.1>
  171 
  172 [...]
  173 >>... Since amavis is smart enough not to include the virus in the DSN,
  174 >>the notice the sender receives is at least "clean".
  175 >
  176 >But the wrong person gets it.
  177 >
  178 >At least when one of my clients tries sending email through my SMTP
  179 >server, they'll get the rejection notice immediately. The mail won't go
  180 >anywhere, they won't get any bounce, they just get a message from their
  181 >MUA saying that the message was rejected.
  182 
  183 [Robert LeBlanc talking about Postfix and dual-sendmail-setup,
  184  not about the Sendmail milter setup (Mark)]
  185 
  186 This assumes that your MTA "handles the rejection [from amavis] properly",
  187 of course.  MTAs know nothing about viruses (or spam for that matter), so
  188 they can't do the rejection themselves on this basis.  When clients send
  189 mail through your MTA, your MTA relays that mail to amavis, which does the
  190 content-checking.  If amavis finds a virus and uses D_REJECT, the
  191 responsibility falls back to your MTA to decide what to do.  When MTAs
  192 receive a permanent failure SMTP error (i.e. 5xx), they try to be helpful
  193 by generating DSNs that include the full original mail, to send back to the
  194 sender, explaining the rejection.  Your client would then get the virus
  195 sent back to him in the DSN.
  196 
  197 This is harmless (quite helpful, actually) when the sender happens to have
  198 an old-style virus, of course, but with the "viruses that fake sender
  199 addresses" this is a distribution method.  Consider that your user has one
  200 of these viruses on his machine and it starts spewing out copies of itself
  201 through your mail server, all with fake sender addresses.  When your MTA
  202 sends out its DSNs to those fake addresses, those DSNs will contain the virus.
  203 
  204 If you'd used D_BOUNCE instead, the DSNs would be issued by amavis (which
  205 is virus-aware) rather than your MTA (which isn't), so the mail going to
  206 those fake senders would be virus-free.
  207 
  208 My point is that your idea of "reject at the MTA" doesn't work as such,
  209 because the MTA does not have a virus scanner embedded in its own
  210 logic.  The rejection takes place at the content-filtering stage (i.e.
  211 amavis), so the rejection is handed to the MTA by amavis, rather than from
  212 your MTA to the client.  Your MTA will still produce a DSN and helpfully
  213 send back the original mail--that's what SMTP dictates that it *must*
  214 do.  You're better off using D_BOUNCE and letting amavis issue its own DSN,
  215 so that at least you won't be spreading the virus itself any
  216 further.  *Both* methods generate spam-by-proxy, but one of them also
  217 spreads viruses.
  218 
  219 The closest thing to an "ideal" solution, in my (admittedly biased)
  220 opinion, is what I refer to as the "discard safely" policy--D_DISCARD items
  221 like these after quarantining them--provided that you have a quarantine
  222 management system (e.g. Maia Mailguard) that lets users access these
  223 quarantined items.  No DSNs get sent out, as the mail is effectively
  224 "accepted" (into quarantine), and the local recipients have access to this
  225 special mailbox to retrieve anything they want to keep, so there's no
  226 *need* for a DSN--the mail was, for all intents and purposes, successfully
  227 "delivered" to the recipients.
  228 
  229 
  230 Robert LeBlanc
  231 Renaissoft, Inc.