[OJS 3.5.0.1] gmail configuration fails with SSL: Connection reset by peer

Describe the issue or problem
After upgrading to 3.5.0, all emails sent via OJS end up in spam, probably due to subtle changes in DMARC compliance in the latter version. Since control over our server infrastructure is limited, I’m looking for a more solid SMTP configuration for our journal than the mail server on our system. I’m trying to configure SMTP via gmail, following the instructions at https://docs.pkp.sfu.ca/admin-guide/en/deploy-email#gmail.

There seems to be a problem, however: whenever sending a mail via OJS, following error is logged:

[Fri Oct 10 08:01:47.254481 2025] [php:notice] [pid 13:tid 13] [client 172.26.0.8:48212] Connection could not be established with host "ssl://smtp.gmail.com:465": stream_socket_client(): SSL: Connection reset by peer, referer: https://my.journal.org/index.php/test/management/settings/access

Steps I took leading up to the issue
Configured email in config.inc.php as follows:

smtp = On
smtp_server = smtp.gmail.com
smtp_port = 465
smtp_auth = ssl
smtp_username = <email>
smtp_password = <password>
allow_envelope_sender = On
default_envelope_sender = <email>
force_default_envelope_sender = On
force_dmarc_compliant_from = On

…and trying to send test emails via the Settings > Users & Roles page.

Result:

  • no email is delivered
  • logs show message
[Fri Oct 10 08:01:47.254481 2025] [php:notice] [pid 13:tid 13] [client 172.26.0.8:48212] Connection could not be established with host "ssl://smtp.gmail.com:465": stream_socket_client(): SSL: Connection reset by peer, referer: https://my.journal.org/index.php/test/management/settings/access

What application are you using?
OJS 3.5.0-1

Hi @rvdb,

Please check DMARC compliance logic ordering causes SES/SMTP failures · Issue #11766 · pkp/pkp-lib · GitHub to see if it’s resolved with the patch provided there. This will be included in OJS/OMP/OPS 3.5.0-2 when it’s released.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks for your suggestion, @asmecher . That fix doesn’t solve this issue, which really seems to be a problem establishing a connection with the smtp.gmail.com server at port 465 (and 587, tried that port as well). I’m running OJS within a docker container, maybe the problem lies there, but I’m suspecting it’s an issue with the host server.

Yet, the reason why I was trying a configuration with smtp.gmail.com was to see if that could improve the OJS-3.5.0.1 email regression when sending from our own domain I had reported separately in [OJS-3.5.0] how to force default email address for all emails sent by the system? - #3 by asmecher . That issue has (or will) be resolved by the patch you mentioned, so I can continue without gmail.

Best,

Ron

1 Like

Greetings, I implemented the DMARC update, but our emails are still sent from default cPanel email. We tried updating the following:

; Default method to send emails
; Available options: sendmail, smtp, log, phpmailer
default = sendmail

; Path to the sendmail, -bs argument is for using SMTP protocol
sendmail_path = “/usr/sbin/sendmail -bs”

; Use SMTP for sending mail instead of mail()
smtp = On

; SMTP server settings
smtp_server = smtp.gmail.com
smtp_port = 587

; Enable SMTP authentication
; Supported smtp_auth: ssl, tls (see PHPMailer SMTPSecure)
smtp_auth = tls
smtp_username = email
smtp_password = password

; Enable suppressing SSL/TLS peer verification by SMTP transports
; Note: this is not recommended for security reasons
; smtp_suppress_cert_check = On

; Allow envelope sender to be specified
; (may not be possible with some server configurations)
allow_envelope_sender = On

; Default envelope sender to use if none is specified elsewhere
default_envelope_sender = email

But it’s still not working. Please help.

Note, we are using shared hosting provided by namecheap.

Hi @muhdlawal,

I think the problem is the default setting. You have it set to sendmail, but it should be smtp.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher, thanks a lot for your response. This solved our problem.

This topic was automatically closed after 11 days. New replies are no longer allowed.