Run a report on any emails that didn't go out

Describe the problem you would like to solve
Our managers are not being notified when emails are not delivered.

Describe the solution you’d like
A report that Journal managers can run would be helpful.

Who is asking for this feature?
Tell us what kind of users are requesting this feature. Journal Managers
Additional information
Add any other information or screenshots about the feature request here.

Hi Stephen,

It’s possible that there’s some mechanism I’m not aware of – but generally OJS is able to successfully deliver messages to the mail server (SMTP or sendmail, depending on your configuration); it’s the delivery from there to the receiving server that fails, without notifying OJS of the failure. So as far as I’m aware it isn’t possible for OJS to know whether or not a message was delivered.

Regards,
Alec Smecher
Public Knowledge Project Team

Interesting FR. With an increasing dependence on mailing systems (registration, notifications…) probably worth to explore tecniques to get alerts if something is not working “as usual”?

I am not an expert on the subject but I can think of a few ideas that may not be stupid:

  1. Bounce statistics: configure ojs to read the returned mailbox and present statistics with the number of total cases and grouped by reason.
  2. Email tracking: Using techniques such as “Tracking Link”, “Header Analysis”, “Digital Signatures and Certificates” or “Pixel Tracking” it would be possible to track emails… although each case must be analyzed to ensure that the privacy of individuals is guaranteed and if the technique is minimally reliable (e.g. adding a blank pixel to know if the mail is opened at destination, requires that the destination accepts to see the images and also should be implemented to anonymize the data to be an attack on the privacy of individuals).
  3. Ask the servers: Marking mails with “Delivery Confirmation”, “Read Receipt”, “Receipt of response”… that would only work with those servers that allow it.

As far as I know, there is no technique that is 100% reliable, but there is no need for it to be… since what is sought is an approximate mechanism, which allows to know to what extent the malings are working as usual or if there is any problem that requires the intervention of technicians.

@asmecher what if we move this to a Discussion till we have a better idea about what we need?

Hi @marc,

I’m happy to kick ideas around here – I don’t think there’s much value in having both a forum topic here and a Github discusison.

Thanks,
Alec

1 Like

It would be possible to define a Return-Path to receive bounced messages, with VERP to identify the origin of each returned message.

For example, messages from the PKP Forum use this mechanism and will have a header similar to this:
Return-Path: replies+verp-56344545efdcdfd8de084eb9e939fdf6@forum.pkp.sfu.ca

In addition to the above mechanism, there is the Feedback Loop (FBL) to receive notifications from users who are considering the messages spam.

Then there’s the header that makes it easier for users to unsubscribe, which was added in OJS 3.4 recently.

1 Like

@asmecher What is the link to the Github discussion on this? Thanks

No github Discussion.
I made the proposal but Alec suggested to keep talking here and I’m ok with both… so let’s talk here.

Diego, I didn’t know about VERP and it’s really interesting. Thanks for sharing.
My only concern is, what would happen if your MTA is wrongly added to a black list?

Any mecanism implemented need to take in consideration this, so admin could rollback from a range of dates.

I feel for a complete solution mailing need to be understood as part of (or connected) with user management.
In past I found journals in my service with a lot of spam users… that will make mailings big and more suspicious, and looks like a downside with VERP. So tooling for cleaning the user list it’s also a “nice to have related” feature.

But back to the point VERP + some statistics about mailing results, sounds like a great solution.