The retry db's (if I'm correct - this is just a guess) store the IP address
of the mail server that a particular domain is on. If a mail server fails
to work properly (according to Exim), then it will set the retry value for
delivery later. This entry ties with the domain name, so that if another
domain is found to use the same mail server IP, Exim assumes that no
delivery should be tried until the retry limit is reached.
By using the retry_use_local_part setting, you're now including the local
part of the email address to the retry db along with the domain name. So
now the mail server IP is tied to a full email address, so the retry times
are specific for individual users. If one email fails to deliver properly,
it sets the retry time for that specific user and it doesn't affect any
other user/domain that uses the same mail server.
So it's not that it stores the local part INSTEAD of the domain (as it
sounds like you thought?), so there's no problem with it holding up in any
circumstance - it just means your retry db will be much larger, and your
bandwidth usage may be considerably more as well as more retry attempts
going on at any one time since your retry db will be user specific rather
than domain specific.
Also, using check_local_user isn't required for this - I don't use it
because my mail servers don't have actual user accounts, so check_local_user
would always fail for my setup. I wouldn't say this is any configuration or
RFC issue - just an option which can help you fine tune your retry database
entries so that the masses aren't held up when one person jumps the fence.
Eli.
-----Original Message-----
From: Ian Garrison [
mailto:bitstream@technoendo.net]
Sent: Monday, January 26, 2004 4:58 PM
To: Eli
Cc: exim-users@???
Subject: RE: [Exim] exim handling of 5xx fatal errors
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/ ##
>
>
>
>
