I think the suggestion was that if they are bouncing due to the
recipient address being nonexistant, you should set up recipient
verification, so that you don't accept mail for recipients that don't
exist in the first place, regardless of wether its spam or not.
If they are bouncing for some other reason, then you might consider the
following options:
-----------------------------------------------------------------------
ignore_errmsg_errors Type: boolean Default: false
If this option is set, failed addresses in error reports (that is,
bounce messages, whose senders are '<>') are discarded (with a log
entry). The default action is to freeze such messages for human
attention.
ignore_errmsg_errors_after Type: time Default: 0s
This option, if it is set to a non-zero time, acts as a delayed version
of "ignore_errmsg_errors", which must be unset for this option to take
effect. When an error message that was frozen because of delivery
failure has been on the queue for more than the given time, it it
unfrozen at the next queue run, and a further delivery it attempted. If
delivery fails again, the error message is discarded. This makes it
possible to keep failed error messages around for a shorter time than
the normal maximum retry time for frozen messages. For example,
ignore_errmsg_errors_after = 12h
retries failed error message deliveries after 12 hours, discarding any
further failures. For ways of automatically dealing with other kinds of
frozen message, see "auto_thaw" and "timeout_frozen_after".
-----------------------------------------------------------------------
On Wed, 21 Feb 2001 O.Cook@??? wrote:
> Bernard,
>
> Clearly it would be best to block the spam, but this is inevitably not
> possible in _every_ case.
>
> Therefore what I am looking for is an option, or a retry rule perhaps,
> that would make outgoing bounce messages for these spam not have their
> delivery treated the same as normal outgoing messages.
>
> To clarify, the bounce message that is being sent out is of the form "no
> such user here", and is not being delivered because the return address
> on the spam is invalid. I'm just trying to prevent having messages in
> the spool for unnecessarily long periods.
>
> I would prefer for these bounces to only have their delivery attempted
> for a day at most, rather than the default week that the rest of my
> outgoing messages are tried for.
>
> My initial reaction was to set a retry rule of the form "<>@* * F,1d,2h"
> but that isn't a solution it would seem.
>
> Thanks,
>
> Ollie
>
> -----Original Message-----
> From: Bernard Stern
> Sent: Wed 2/21/2001 13:47
> To: exim-users@???
> Cc:
> Subject: RE: [Exim] retry rules for bounce messages
>
>
>
>
> On Wed, 21 Feb 2001 13:25:10 -0000 O.Cook@???
> wrote:
>
> > Is it possible to make a retry rule for bounce messages, such
> that they
> > don't stay on the queue for too long? My main concern is
> bounce messages
> > from incoming spam, that will never get delivered back to the
> fake
> > sender address.
>
> > Thanks,
>
> > Ollie
>
> I'd suggest you best don't accept such mail at all, reject it
> at RCPT TO. Chapters 45 and 46 of the exim spec document. Or
> is there something that I did not understand in you message?
>
> Regards,
>
> Bernard Stern, SWITCH
>
> ____________S_W_I_T_CH___Swiss
> Academic_______________________________________
> mail: SWITCH Head Office a Tel: +41 1 268
> 1520
> Limmatquai 138 n Fax: +41 1 268
> 1568
> CH-8001 Zurich d e-mail:
> stern@???
> ________________________________________Reseach
> Network_______________________
>
> --
> ## List details at
> http://www.exim.org/mailman/listinfo/exim-users Exim details at
> http://www.exim.org/ ##
>
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
--
