"manager setup email Header Description" deleted in OJS 2.4.8.1

Hi!

Is there any reason why was aliminada the “manager.setup.emailHeaderDescription” on OJS 2.4.8.1?

“Manager.setup.emailHeaderDescription” is very useful for headers when sending an email from OJS.

ojs/templates/manager/setup/step1.tpl

Here you can compare the code for each version and see what has been removed:

OJS 2.4.8.0

OJS 2.4.8.1

Thanks!!

In OJS 2.4.8, we briefly changed to sending emails from the Journal’s principal contact with a reply-to of the actual sender. Because this was potentially confusing to the recipient, we added the “email header”. This caused different confusion and technical problems. In 2.4.8-1, we returned to a default of sending the email from the actual initiating user, and the email header was dropped.

If you wanted to re-add this functionality as a local modification, you could search for “Header” in this commit:

1 Like

Hi! @ctgraham

Thanks for reply!!

You are a great help!!

Dear @asmecher

Just a note that the same files (the patch supplied above) is missing in OJS2.4.8-2 (latest from Github). Could you kindly include this is the Github. Thanks

Hi, @tretief. This modification was intentionally deleted. If you want to have an email header in your installation, you’ll need to maintain a local code modification yourself.

Hi, @ctgraham - I understood the code to do the following:

  1. email header found in the Journal Manager >> Setup
  2. sender of system emails, primary contact ; if reply-to field populated with original senders email.
    Was (1) and (2) intentionally deleted? If so, could you remember the reason?

To explain my question, the intent of introducing these changes were: “the journal’s outgoing emails being flagged as “spoofed” by some email servers, since the email addresses in question (eg. james@myinstitution.org”) didn’t match the domain name of the server sending the email (eg. “myjournal.com”). (Technically, the emails were failing Sender Policy Framework (SPF) validation.) Being flagged in this way is more serious than being considered spam: in many cases, the receiving email server won’t even assign the email to a spam/junk queue, instead simply choosing to discard it."

The email header was introduced essentially as a disclaimer for the nonstandard way we were handling technical compliance with modern email standards. It was removed with better native email support:

I do think the option of the reply-to address should be retained, at least for now. That pull request is here:

In your situation, it may be that the best option would be to modify the SPF records to allow myinstitution.org senders for myjournal.com. Alternately, reintroducing the force_envelope_sender option with a reply-to is another approach which I want to see re-added to core. The topic of this thread is specific to the use of the freeform text of the “email header description”, which is unlikely to make another appearance in the product.

Thanks @ctgraham - read your feedback and appreciate the prompt response. Will divert this to our Technical Department for further discussion and review.