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 [email protected] -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
