https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43340
--- Comment #22 from Martin Renvoize (ashimema) <[email protected]> --- Created attachment 210740 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=210740&action=edit Bug 43340: Retry with backoff when the SMTP server reports a temporary failure When the mail server answers with a temporary failure, Koha marks the message failed with the failure code SENDMAIL and moves on to the next message. Nothing ever tries that message again unless a librarian notices it and clicks "Resend". Google's SMTP relay in particular will sometimes answer the EHLO with: Net::SMTP=GLOB(0x55eba2c35700)<<< 421-4.7.0 Try again later, closing connection. (EHLO) The throttle only lasts a few seconds, but every remaining message in that run opens a new connection, gets the same 421, and is marked failed. On one busy site the cron logs show bursts of 53, 164 and 248 consecutive failed hold notices inside a single run of process_message_queue.pl, after which the next run 15 minutes later sends everything without a problem. Every one of those notices was lost. This patch makes Koha treat a temporary failure the way an MTA would. A 4xx response from the mail server, or a connection that is refused before Koha gets a response code ( which is what a 421 at the EHLO stage looks like to Email::Sender ), leaves the message pending with a retry_after time and bumps send_attempts. The message is tried again by a later run of process_message_queue.pl after 10 minutes, then 30, 60 and 120 minutes. Only if the fifth attempt also fails is the message marked failed with SENDMAIL as before. Permanent failures are still marked failed right away. Once a server has refused a connection or answered 421 during a run, the remaining messages for that server are deferred without trying to connect, so a server that is rate limiting us sees one connection per run instead of one per message. Resending a message from the notices tab starts the schedule over. Note that an immediate send ( password recovery, for example ) now reports the message as not sent when it was deferred; the message still goes out with the next cron run. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Restart all the things! 4) Point your default SMTP server ( Administration > SMTP servers ) at a host and port where nothing is listening 5) Queue notices for several patrons with email addresses, e.g. check out items with the CHECKOUT notice enabled 6) Run misc/cronjobs/process_message_queue.pl 7) Note a single connection failure in the output followed by a line saying the server is unavailable, and that every notice is still pending! 8) Run process_message_queue.pl again, note the messages are skipped! 9) UPDATE message_queue SET retry_after = NOW() WHERE status = 'pending' 10) Run process_message_queue.pl, note send_attempts is now 2 and retry_after is 30 minutes out! 11) Repeat steps 9 and 10 until the messages are marked failed with "Unhandled email failure" on the patron's Notices tab! 12) Point the SMTP server back at a working mail server 13) Click Resend on a message, run process_message_queue.pl, note the message is sent! Signed-off-by: Brendan Lawlor <[email protected]> Signed-off-by: Martin Renvoize <[email protected]> -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
