View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0030127||mantisbt||public||2022-05-05 16:19||2023-04-11 19:07|
|Target Version||2.25.7||Fixed in Version||2.25.7|
|Summary||0030127: new PHPMailer() is created for every outgoing email|
global $g_phpMailer is not set, so a new PHPMailer() is created for each message, causing a new smtp login for each message, many rapid logins can upset a mail server.
If not using cron to trigger send: anything that triggers a send will cause the app to hang for all users, and possibly timeout (while it tries to send all the backed up mail).
Other than delayed (or no) mail, there is no indication of an error in the log unless SMTPDebug>0 and Debugoutput is set to a function that calls log_event() with a log level that is being logged.
|Steps To Reproduce|
Large mail queue and smtp service that blocks after several rapid logins (eg. gmail)
|Tags||No tags attached.|
While I do agree that the global $g_phpMailer variable should be initialized per your suggestion, please note that you may still run into the same issue with your mail provider if your site is very active since processing of the mail queue is triggered after every page load, although the risk would be reduced with this fix.
This is one of the reasons why we recommend to use a cronjob to send e-mails.
Turns out this is a fifteen-year-old bug... MantisBT master b847c593 (1.2.0a3)
MantisBT: master-2.25 28c9d1a6
|Set $g_phpMailer after creating PHPMailer object
Since commit b847c5936ac7579d6bdfaa90ce1c08d1aa874231, the global var
is no longer initialized, causing a new PHPMailer object to be created
with each call to email_send().
When $g_phpMailer_method = PHPMAILER_METHOD_SMTP), depending on the
SMTP server's settings, this could cause a delay when sending mail
(e.g. if more messages are queued than allowed by the server's cooldown
period) and if $g_email_send_using_cronjobjob is OFF, MantisBT could
hang or even timeout.
|mod - core/email_api.php||Diff File|