View Issue Details

IDProjectCategoryView StatusLast Update
0029585mantisbtemailpublic2023-10-31 16:32
Reporterpenguin86 Assigned Tocommunity  
Status closedResolutionfixed 
Product Version2.25.2 
Target Version2.26.0Fixed in Version2.26.0 
Summary0029585: Unable to set the In-Reply-To header to a domain different from the current one

When sending an email via Mantis email api, the In-Reply-To header is treated differently from the others: the value provided is concatenated with the hostname and enclosed in angular brackets (see email_api.php, function email_send() at lines 1422 and following). This prevents setting a custom In-Reply-To.

To provide a use case, I'm currently implementing a "issue created" acknownledgment in Email Reporting plugin. Being the aknowledgement email a response to the reporter's one, I need to send it with In-Reply-To field containing the original Message-ID, as per rfc822. The reporter's email MessageID may not come from the same server Mantis is installed on, so it may have a different hostname.

The most right solution could be simply removing the relevant case, allowing to specify the full header, like this:
For what I can see, the only place where it is used in Mantis is in email_bug_info_to_one_user() (email_api.php:1682), that should be changed to include the hostname (maybe refactoring the code used to obtain the hostname, see email_api.php:1190, in a function?).

But this may eventually break the plugins using that header (are there any?), so another solution could be check for the <>@ symbols and add the hostname only if not already present, like here:

Please let me know which solution you find accettable, so I can submit a pull request.

Thank you very much!

Steps To Reproduce

Send an email (e.g. from a plugin calling email_store()) specifying a complete In-Reply-To header

TagsNo tags attached.


related to 0008706 closedgiallu Bad email headers for notifications 




2022-02-10 09:02

developer   ~0066235

After a bit of research, it appears the switch() statement in email_store() was introduced in MantisBT master 29ec1030 to fix 0008706. According to that, the purpose was to allow threading for notifications sent by MantisBT.

I don't much like the idea of setting the full in-reply-to header including hostname in email_bug_info_to_one_user(), which would be necessary with option 1 - it feels like a hack, doing things out of sequence.

The 2nd option seems preferable (i.e. only add the hostname if none is present) as it guarantees backwards compatibility.

As a side note, I don't think setting the hostname to $_SERVER['SERVER_NAME'] (see email_store() function, line 1187) is a very good idea, as it may allow spoofing.



2022-02-10 10:50

reporter   ~0066236

Thank you, dregad!
I created a pull request for the 2nd option (minus the SERVER_NAME part):
Let me know what do you think about and if I can help further.

Related Changesets

MantisBT: master 4e5ac29b

2022-02-17 16:54

Daniele Verducci

Committer: community

Details Diff
Only add hostname to In-Reply-To header when needed

When sending mail via Mantis email api, the In-Reply-To header was
treated differently from the others: the value provided was
concatenated with the hostname and enclosed in angular brackets,
which prevented setting a custom In-Reply-To.

We now only add the hostname when one is not already present.

Fixes 0029585, PR

Co-authored-by: Daniele Verducci <>
Affected Issues
mod - core/email_api.php Diff File