Increased SPAM issues in OJS 3.1.2.4

Dear community,

first of all, most of the mails we send are not classified as spam. But since our last update to OJS version 3.1.2.4, we have an increasing problem with outgoing mail being classified as spam.
Two cases occur particularly often: Firstly, mails addressed to reviewers. I estimate the delivery errors at 10 to 20 percent. Secondly, mails that are automatically sent to co-authors, who are not the main contact, after their successful submission of the contribution. These mails are almost always classified as spam. The author who is the main contact however receives his mails without problems.

Sending mails to myself (from journal manager to journal manager) for testing purposes just works fine.

These are our mail settings in the config.inc.php

[email]

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

; SMTP server settings
; smtp_server = mail.example.com
; smtp_port = 25

; Enable SMTP authentication
; Supported mechanisms: ssl, tls
; smtp_auth = ssl
; smtp_username = username
; smtp_password = password

; 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 = a****@zeitschrift-suburban.de

; Force the default envelope sender (if present)
; This is useful if setting up a site-wide no-reply address
; The reply-to field will be set with the reply-to or from address.

force_default_envelope_sender = on

; Force a DMARC compliant from header (RFC5322.From)
; If any of your users have email addresses in domains not under your control
; you may need to set this to be compliant with DMARC policies published by
; those 3rd party domains.
; Setting this will move the users address into the reply-to field and the
; from field wil be rewritten with the default_envelope_sender.
; To use this you must set force_default_enveloper_sender = On and
; default_envelope_sender must be set to a valid address in a domain you own.
force_dmarc_compliant_from = on

; The display name to use with a DMARC compliant from header
; By default the DMARC compliant from will have an empty name but this can
; be changed by adding a text here.
; You can use '%n' to insert the users name from the original from header
; and '%s' to insert the localized sitename.
; dmarc_compliant_from_displayname = '%n via %s'

; Amount of time required between attempts to send non-editorial emails
; in seconds. This can be used to help prevent email relaying via OJS.
time_between_emails = 3600

; Maximum number of recipients that can be included in a single email
; (either as To:, Cc:, or Bcc: addresses) for a non-privileged user
max_recipients = 10

; If enabled, email addresses must be validated before login is possible.
require_validation = On

; Maximum number of days before an unvalidated account expires and is deleted
validation_timeout = 14

The header of mails with delivery errors contains the following information:

A message that you sent was rejected by the local scanning code that
checks incoming messages on this system. The following error was given:

  This message was classified as SPAM and may not be delivered

------ This is a copy of your message, including all the headers. ------

Received: from suburban by cpanel10.xodox.de with local (Exim 4.92)
	(envelope-from <a****@zeitschrift-suburban.de>)
	id 1j0v0F-00DEZ4-Lb
	for b******.v*****@sofi.uni-goettingen.de; Sun, 09 Feb 2020 23:24:35 +0100
To: "Prof. Dr. B******* V*****" <b*****.v*****l@sofi.uni-goettingen.de>
Subject: [sub\urban]
X-PHP-Script: zeitschrift-suburban.de/sys/index.php/suburban/submission/saveStep/4 for 77.8.181.125
X-PHP-Originating-Script: 1136:PHPMailer.php
Date: Sun, 9 Feb 2020 23:24:35 +0100
From: a****@zeitschrift-suburban.de
Reply-To: "Redaktion sub\\urban" <i***@zeitschrift-suburban.de>
Message-ID: <bBDevIFVy7nwUiR097PPGiz5O5qYIJUlmZ7rnYsSY@zeitschrift-suburban.de>
X-Mailer: Public Knowledge Project Suite v3
X-Originating-IP: 77.8.181.125
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="b1_bBDevIFVy7nwUiR097PPGiz5O5qYIJUlmZ7rnYsSY"

This is a multi-part message in MIME format.
--b1_bBDevIFVy7nwUiR097PPGiz5O5qYIJUlmZ7rnYsSY
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

Cg==

--b1_bBDevIFVy7nwUiR097PPGiz5O5qYIJUlmZ7rnYsSY
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGJyLz4=


--b1_bBDevIFVy7nwUiR097PPGiz5O5qYIJUlmZ7rnYsSY--

These mails do not appear in the email_log table in our database.

How can I solve the errors when sending mails? Do you have any suggestions? Could switching to SMTP possibly fix these delivery errors?

Warm regards,
Michael

We are also seeing more messages classified as spam with OJS 3.1.x compared to OJS 2.x.

At first I suspected that in part the fact that OJS 3 sends several notifications without content, but indicating a link for the content to be seen when accessing OJS caused some users to mark the message as spam and training their supplier (gmail, outlook ) to do this automatically in the next similar messages.

Elsewhere, that the fact that they are short messages (without the content) with almost only one link, would be detected as suspected spam more easily by some providers.

But currently the biggest problem we are seeing is quite different: there are many “fake” registrations occurring that manage to circumvent google recaptcha in some way.

These “fakes” users use many non-existent addresses. When OJS tries to send messages to them, it reduces the IP reputation of the server. If these users are not excluded, the problem is aggravated with each new sending attempt.

In this sense, we will try two actions:

Hi @abadan

At PKP’s end we are putting effort into searching and providing accessible solutions for a broader range of users, and it doesn’t matter whether they are disabled.
On that note, from the University of Pitt we have 2 plugins that can prevent spamming influx there are plugins that approach Honeypot solutions.

This plugin verifies new user registrations by creating a honeypot on the User Registration form.

This other verifies new user registrations via the Akismet anti-spam service. Subscription to Akismet is required.

Both are good solutions for situations that you can’t or don’t use Google Recaptcha and they don’t add any extra workload on users.

Best,
Israel

Thank you, Israel.
My last link (action indication) is precisely indicating these plugins :slight_smile:

1 Like

Michael,

Your server is sending mail from cpanel10.xodox.de as a user from zeitschrift-suburban.de.

The domain zeitschrift-suburban.de does not provide an SPF record, so receiving MTAs cannot validate that cpanel10.xodox.de is allowed to send mail on behalf of users from zeitschrift-suburban.de. This is a huge flag for spam detection.

Further, messages should be signed by DKIM to validate that the originating sender is who they claim to be. A lack of DKIM signature is an additional flag for spam detection.

SPF should be setup in your DNS records. DKIM should be setup on the sending server and in your DNS records. Changing your config.inc.php settings to use a SMTP service which already has this configured at the service level, and using an default_envelope_sender which is recognized by that SMTP service, is a quick solution.

2 Likes