Re: [exim] Why does exim keep retrying?

On Sat, Aug 31, 2013 at 12:44:12AM -0700, Robin Powell (from phone) wrote:

> There are 3000+ retry database entries for *every* gmail IP, AFAICT.
>
> It's insane. I'm doing something very wrong, and I don't know why.
>
> When a 421 comes in, I want mail to that host to just *stop*, for
> the full 12 hours.

I apologize up front for the lengthy reply, just wanted to help give
some insight into the behavior you're seeing.

Normally when a message gets a deferral after connection or RCPT TO in
an smtp session, an entry in the retry database is made with a retry
key of the DOMAIN+HOSTIP. The idea is that there may be something
preventing delivery to that host, possibly for a specific recipients.

In your case, however, the deferral is coming at end of DATA in the
smtp session. This makes Exim believe that there is something unique
about that particular *message*, and as such, the retry key becomes
DOMAIN+HOSTIP+MESSAGEID.

There are details of this behavior in the Exim docs in section 45.2
under the section "Message Errors".

So upon your delivery attempt, Google defers at end of data, Exim
thinks Google has a problem with that specific message, and defers
that specific message 12 hours. When the next message comes up for
delivery, there is no match retry database entry since all the entries
are for specific messages, not Google's hosts themselves. Therefor
this second message gets a delivery attempt, and it too gets it own
message-specific retry db entry. Wash, rinse, repeat.

Each individual message should get properly defered 12 hours, but new
deliveries still keep being attempted. Also keep in mind that
changing your retry rules doesn't affect messages already keyed in the
retry database. Only new entries pick up new timings.

Now, that being said, I'm not aware of any knob that can be turned to
change this behavior. The code is very straight-forward in the source
code to change (transports/smtp.c and retry.c), but I'm not sure I can
think of a quick and elegant work-around.

Understanding the problem is half the battle. Perhaps someone who has
tackled this issue before has some more insight into it?

--
Dean Brooks
dean@???