Bug 30013

Is this the sort of functionality that was taken care of when we used postfix or similar on the server, and that we loose when moving to using the SMTP functionality in Koha?

From RFC5321, page 66:

The sender MUST delay retrying a particular destination after one
attempt has failed.  In general, the retry interval SHOULD be at
least 30 minutes;

How do we know what the error is? Koha::Email uses Email::Stuffer as a base with uses Email::Sender::Simple which throws an Email::Sender::Failure exception. If we know what the code for that is, we add a new 'retry' status, and a 'retry_after' timestamp such that process_message_queue.pl will only attempt to send retries after that timestamp.

This also happens when using google as a provider of smtp.

Not sure if this will be solved by 33360.

(In reply to Liz Rea from comment #4)
> This also happens when using google as a provider of smtp.

Yes, I wrote 33360 with mail deferrals from google in mind.

(In reply to Magnus Enger from comment #5)
> Not sure if this will be solved by 33360.

Yes. But the current -limit is already doing that partially. The domain limits will be additional.

(In reply to Kyle M Hall from comment #3)
> How do we know what the error is? Koha::Email uses Email::Stuffer as a base
> with uses Email::Sender::Simple which throws an Email::Sender::Failure
> exception. If we know what the code for that is, we add a new 'retry'
> status, and a 'retry_after' timestamp such that process_message_queue.pl
> will only attempt to send retries after that timestamp.

In many cases Koha will just send to port 25. If the local mta receives it, Koha marks it as sent. But the mail is not yet outside. E.g. My local mta is now trying to send it to my mail container. Which also receives it and the problem comes up there.

Bug 33360 tries to throttle a bit smarter than the current limit does by looking at recipient domains too.

*** This bug has been marked as a duplicate of bug 33360 ***

I don't believe 33360 fixes this issue - this is about using google as a smtp server and the fact that our message queue opens a connection per message to the smtp server. Near as I can tell 33360 has to do with the recipients and sender limits of the emails, not the behaviour of the smtp server. Google wants each connection to send several mails, right now we only send one message per connection.

Google does not publish the limits, but does say that smtp server connection limits are some number per rolling 24 hour period. They prefer the connection be kept open rather than making many individual connections.

I think we need to implement https://metacpan.org/pod/Email::Sender::Transport::SMTP::Persistent and keep the instances of it in memory during each call to SendQueuedMessages

(In reply to Kyle M Hall from comment #11)
> I think we need to implement
> https://metacpan.org/pod/Email::Sender::Transport::SMTP::Persistent and keep
> the instances of it in memory during each call to SendQueuedMessages

+1

Since different libraries can have different SMTP servers, I reckon SendQueuedMessages should have an empty hashref that gets passed through to _send_message_by_email. (Looks like _send_message_by_email is only used in SendQueuedMessages so changes to the arguments should be easy.)

Then the $stmp_server can be cached in that hashref for the life of SendQueuedMessages.

(In reply to David Cook from comment #12)
> (In reply to Kyle M Hall from comment #11)
> > I think we need to implement
> > https://metacpan.org/pod/Email::Sender::Transport::SMTP::Persistent and keep
> > the instances of it in memory during each call to SendQueuedMessages
> 
> +1
> 
> Since different libraries can have different SMTP servers, I reckon
> SendQueuedMessages should have an empty hashref that gets passed through to
> _send_message_by_email. (Looks like _send_message_by_email is only used in
> SendQueuedMessages so changes to the arguments should be easy.)
> 
> Then the $stmp_server can be cached in that hashref for the life of
> SendQueuedMessages.

And that's exactly what you've already done. Just saw the other report heh.

So we can close this one and look at 33964 instead..

*** This bug has been marked as a duplicate of bug 33964 ***