[Exim] High queue volume due to "broken" SMTP server

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Eli
Fecha:  
A: exim-users
Asunto: [Exim] High queue volume due to "broken" SMTP server
I've got a pair of systems which are set up as filtering systems - they just
filter messages for spam/virus and then pass the email on to the real SMTP
servers via manualroute.

Everything is working, however the real SMTP servers have an RFC violation
in which they will sometimes just close the connection after DATA with no
5xx error (well, it does give a 550 error, but no terminating newline, and
it shuts the connection down as soon as you type in DATA, not after the
message has been sent). I've emailed the programmers for that daemon,
however I am still trying to figure out a way to change how Exim retries
messages destined for this router/transport.

I have retry_use_local_part set in my router to try and prevent one users
message from "blocking" all other messages since they're all destined for
the same IP, however I'm not 100% sure it's doing what I hoped.

What is happening is that once in a while, a message to be manualrouted
fails (for whatever reason). Exim updates its hint file for the router and
then all the messages that were queued for that server now get a new retry
time. I think this is causing messages that have even hit their time to be
retried to just get postponed again because another msg updated the retry
time for the IP.

Is there any way to specify a different retry rule based on router? Is
there any way to specify a different retry time based on the IP of the
server I'm trying to contact? Or even best, is there some way I can verify
that retry_use_local_part is keying the wait- db for my router with email
addresses as well as the IP to send to?

Any ideas or whatever on how I can try to overcome this would be greatly
appreciated. My queues are in the thousands and the emails are perfectly
deliverable for about 80-90% of them yet they just linger away (hopefully
getting delivered before generating bounce messages! Yikes!)

Eli.