On Wed, 21 Feb 2001 14:26:33 -0000 O.Cook@??? wrote:
> Bernard,
> Clearly it would be best to block the spam, but this is inevitably not
> possible in _every_ case.
It _is_ possible provided you have a list of all valid local
parts within your local domain(s), which you really should have.
The other way round we end up rehashing what's been said recently
about backup MX.
> 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.
Have you set receiver_verify = true and played with
receiver_verify_hosts, receiver_verify_addresses,
receiver_verify_senders? When you configure these correctly,
then you won't end up with such annoying "no such user here"
bounces to invalid spammers. I also used to have such bounces
in my queue. Configuring the above mentionned parameters
got them off my queue, because you reject such mail at RCPT TO.
> 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.
I think it is always best to solve the problems as close to
the source as reasonably possible. Your attempt is merely a
way to reduce the time such spam sits on your queue, IMHO not
really a good solution. Believe me, the time you'll invest
in this receiver_verify stuff is not wasted.
> Thanks,
> Ollie
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_______________________
