[exim-dev] [Bug 1788] Some deliveries not re-attempted after…

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
Old-Topics: [exim-dev] [Bug 1788] New: Deliveries to one ISP sometimes fail silently after T=remote_smtp defer on first delivery attempt
Subject: [exim-dev] [Bug 1788] Some deliveries not re-attempted after 'T=remote_smtp defer (-53): retry time not reached for any host' on first delivery attempt
https://bugs.exim.org/show_bug.cgi?id=1788

--- Comment #36 from Alex Presland <exim@???> ---
Where I say "The spamcatcher2 account processes", it would be more accurate to
say "The eximfilter script/commands/rules in the spamcatcher2 account's
.forward file are run". So yes, it is Exim doing stuff.

Are you asking whether there's some way of eliminating using the spamcatcher2
account from the mail processing. Not really. We've used the power of
eximfilter script/commands/rules in this account's .forward to implemented some
really effective anti-spam rules. This significantly reduces the volume of
spam that the server relays when alias-based email forwarding takes place.
Without it, the spam/ham reputation of the server would be in tatters. This is
due to the fact that, despite implementing SPF (for hosted domains) and SRS for
relayed emails, other mail hosts would still consider forwarded spam to be from
our server.

Our server's SpamAssassin implementation is already using many RBLs which
successfully block & tag a load of spam. Doing domain-based email aliases
alone, SpamAssassin would tag mail as spam and forward it on. One of the
things that the spamcatcher2 account is doing is preventing detected spam from
being forwarded by preventing it from being forwarded off-box.

--
You are receiving this mail because:
You are on the CC list for the bug.