Ahhh! Ok, so retry_use_local_part has exim defer messages for
$local_part instead of the destination mail server? Neat. Will this hold
up well in situations where hundreds of domains are handled and some
possibility that 'joe' is a common alias on a few domains? Don't need to
answer that if you don't feel like it, you have given me the direction I
needed. Thanks!
I forgot we do not use check_local_user so my reported problem may be
moreso related to our config than any kind of rfc related argument with a
vendor.
-ian
On Mon, 26 Jan 2004, Eli wrote:
> 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/ ##
>
>
>
>
