Block auto-replies to spam

[Mark Martinec]

Francis,

> Most of the email sitting in our outbound queue is undeliverable
> auto-replies.  Many of them are already tagged as spam on
> the inbound pass through our SA.
> 
> Much of it comes from "out of office" set up on Exchange.
> I have no control over the users in this regard.
> They feel it is worthwhile to let the small number
> of real email senders know of alternate addresses
> to contact while they are away on vacation, etc.

Perhaps it would help to just lower the bounce_queue_lifetime,
to a day, or down to a couple of hours:


  bounce_queue_lifetime (default: 5d)

    The maximal time a bounce message is queued before it is considered
    undeliverable. By default, this is the same as the queue life time for
    regular mail. 

    Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
    The default time unit is d (days). 

    Specify 0 when mail delivery should be tried only once. 

    This feature is available in Postfix 2.1 and later.


> I saw some documentation reference to running amavisd
> as a pre-queue and it said this was not recommended
> - I do not know why.

The situation is much improved with amavisd 2.7.0 + SA 3.3 +
Postfix 2.7.0 using smtpd_proxy_options=speed_adjust :


amavisd-new-2.7.0 release notes

GENERAL

With a synergy of four solutions, using amavisd-new in a pre-queue
filtering setup became a sensible / better behaved solution:

- the "smtpd_proxy_options=speed_adjust" Postfix option, available since
  Postfix 2.7.0 (20091101), improves decoupling between SMTP clients
  and a content filter in a proxy setup, reducing the number of content
  filtering processes needed for the same mail load. With this option
  turned on, a Postfix SMTP server receives entire message before
  connecting to a before-queue content filter;

- a master_deadline option and its API equivalent, available in SpamAssassin
  since version 3.3.0, allows for time limiting on lengthy rules checking,
  while still providing results when a time limit is exceeded; this makes
  it more suitable for time-sensitive setups like a pre-queue filtering setup;

- reworked sub-task time limiting in amavisd, along with its counterpart
  solution in SpamAssassin, makes it better suited to a real-time nature
  of pre-queue filtering setups where one has no control over how long
  SMTP clients are willing to wait at the data-end stage;

- a re-purposed command line option 'reload' now does a warm restart,
  keeping sockets available to an MTA client at all times, thus reducing
  a chance that an MTA would even notice a content filter's warm restart.

Provided that required minimal versions of Postfix and SpamAssassin are
available, on can try amavisd in a Postfix proxy setup. The $child_timeout
setting needs to be radically reduced in this setup, matching the longest
time most SMTP clients are willing to wait, and must be less than Postfix
is willing to wait (smtpd_proxy_timeout), which by default is 100 s.
A sensible value is somewhat less then a minute (e.g. 45 seconds). Even
though RFC 5321 (section 4.5.3.2.6) recommends that clients SHOULD be
willing to wait for 10 minutes at data-end stage, it is not uncommon
that this recommendation is not adhered to.

Note that a pre-queue filtering setup (along with its benefits) still
has all its drawbacks, like the need for more filtering processes to
accommodate mail arrival rate peaks (instead of averages), and much shorter
and unpredictable (client-dependent) time limits. The new features of the
three products only rise the thresholds where trouble starts, and make
the whole setup better behaved.



  Mark