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.
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:
Bounce statistics: configure ojs to read the returned mailbox and present statistics with the number of total cases and grouped by reason.
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).
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?
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.
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.
Marc, one of the main uses of VERP is to find out that a particular recipient is not receiving your messages and to stop sending messages to them (temporarily or permanently). Not insisting on sending messages to addresses that don’t receive them is a good practice that helps the mail server’s IP not to get blocked.
It’s also much easier for the editor to know that the reviewer who didn’t respond to the invitations isn’t actually receiving the messages. This allows for more effective action. Or for OJS to stop sending new issue publication notifications or announces to a user with an e-mail address who doesn’t receive the messages (non-existent account, for example).
My only concern is, what would happen if your MTA is wrongly added to a black list?
I believe that a good integration of OJS with the e-mail service can reduce the possibility of this blockage occurring and will allow greater visibility of the various possible problems with sending e-mails (IP blockage, account that doesn’t exist, mailbox full, temporary problems in receiving…) from the OJS interface itself.
I agree that it needs to be integrated into the user profile. I’d love to be able to see, from a user’s profile, what has happened with (recent) attempts to send emails. That a reviewer is not receiving the messages before inviting them, which authors of an article have had the editorial decision message bounced, etc.
So tooling for cleaning the user list it’s also a “nice to have related” feature.
It’s on our wish list to develop a plugin to help clean up the user base. It could remove users with no role and who have never been active in a journal (not sent a submission, not evaluated an article, etc.) after a certain period without logging in. In addition, it could remove users with roles such as readers and authors who also don’t have any activity in a journal in their history and who haven’t logged in for a long time. I hope to return to this subject in a specific forum topic when we get a chance.
I wasn’t familiar with VERP either, though I have noticed VERP-ish addresses before and wondered if there was some kind of standard operating there.
We would need VERP to behave consistently across email servers in order to have it work reliably in OJS, and I’m a little concerned about that after a quick experiment on my own server (commodity CPanel hosting run by a2hosting). I sent a message to a VERP-ish address (combining alec@mydomain.com plus me@there.com to get alec+me=there.com@mydomain.com. This resulted in an imap folder tree being created (as I have the cpanel option enabled by default, as most will):
me=there/com
Unfortunately that’s two folders, nested: first me=there, second com. That feels like a pretty big quirk to me!
Can either of you identify a standard this conforms to? Do you see similar with your own clients/servers?
Thanks,
Alec Smecher
Public Knowledge Project Team