You're looking for the "retry_use_local_part" router & transport setting
(boolean). This controls retry db lookups to see if it should include the
local part (user@ portion). This option is enabled by default for any
router that uses check_local_user, and false otherwise - so chances are it's
false for your dnslookup router when you want it to be true.
Eli.
-----Original Message-----
From: exim-users-admin@??? [
mailto:exim-users-admin@exim.org] On Behalf
Of Ian Garrison
Sent: Monday, January 26, 2004 2:36 PM
To: exim-users@???
Cc: bitstream@???
Subject: [Exim] exim handling of 5xx fatal errors
This has probably been discussed, but I still have to ask as googling
and digging around on exim.org hasn't produced much fruit.
Exim (we run 3.35) handles 500 level failures a little differently than
most mta's. Most mta's if a critical failure occur will not process a
critical'd email in a queue run, but exim goes even further to not send
ANY email to the mail server that returned the critical failure for a
queue run.
Consider this scenario:
One has 10k emails spooled up to send to an external mailserver, with
5k being legit and 5k being spam, and the external mailserver does
VRFY-like user checking (return 550 'user not found') because of a spam
firewall they run. As the mailq is flushed the legit emails at the top of
the queue will go through just fine, but when some spam delivery is
attempted exim will defer all mail being sent to that mailserver for the
remainder of the queue run. This leaves legit email stuck in the queue
longer than it should need to be. On the next queue run a few legit
emails are sent, but then a spam or two causes the process to repeat
again. Eventually some portion of legit email has been in the mail queue
for long enough that it is wiped out (we have 5 day queue retention in our
exim config). I'm curious if there is an elegant configuration change to
dodge the issue above, but even more curious as to why exim is different
in handling this problem than most mta's.
Anyway, I am having a discussion with one anti-spam appliance vendor
and pointed out the scenario above, their reply was "exim does not comply
to the rfc's in this regard". They muttered something about rfc 822 and
2822, both of which don't spell out the answer I'm looking for. Can
anybody comment on rfc-correctness of 'stop sending all mail destined to
one mail server that returned a critical error for the duration of one
queue run'? Exim does do something different from the masses and I cannot
see any behavior in such a case as documented in an RFC (suspect its an
implementation detail). Does exim maintain this behavior through all
versions?
It is my opinion that in situations like the one above that its best if
everybody always receives email. They can /dev/null or reroute it
afterwards, but terminating an smtp session with some error code that has
different meaning depending on mta implementation seems screwy (550 might
be 'user not found' for some or 'server not available' for others). This
rids folks of the rumplestiltskin VRFY type attacks (amazes me that this
issue resurfaced, was dealt with in the past with 'turn off VRFY', but has
returned again in antispam products). Always receiving mail seems more
compatable with the majority of mta's, especially exim, and it also keeps
the mail queues free from spam/garbage that is doomed to permanent
failures for its lifespan in the queue. Does anybody see a serious flaw
in my thinking on this point? While I have such opinions it would appear
that the industry doesn't think the same way and I suspect that I'm
missing something. I am not getting an enlightened response from the spam
filtering vendor aside from 'exim is not rfc compliant in this regard, use
something else'.
Please include my email address in any replies as I am not subscribed
to exim-users. Hopefully I am worthy of some feedback from those more
experienced with exim and mta correctness.
Thanks,
-ian
--
## List details at
http://www.exim.org/mailman/listinfo/exim-users Exim
details at
http://www.exim.org/ ##
