[9.5] New IMAP Library Does Not Handle No Reply-To in Email Headers #7643
Comments
|
Seeing this as well...identical in fact. Have tried both IMAP and POP....this is on a new install trying to retrieve email from an Office 365 mailbox. |
|
Ok....further digging.... Exchange environments do not set the Reply-To header. This goes for on-prem as well as Exchange Online. If when sending an email through an Outlook client you client the Options menu, and then click the 'Direct Replies To' button, under Delivery options there will be a checkbox called 'Have replies sent to', and it should have your email name/account pre-populated. Simply click close and send your email....it will now contain a Reply-To header. Upon doing this, the IMAP receiver picks up the mail just fine. Not sure how other mail server environments work, but at least for Exchange, there is no way to set a Reply-To header at the org level, even using transport rules. That's enough about Exchange....just wanted to illustrate what I did to test this......with no changes to my IMAP receiver the above will allow the email to be picked up. If I don't perform the above, I'll receive the same error outlined by the op. After some searching through the php files, what I've done to temporarily fix this, (and only because I'm not in prod with this new instance), I've commented out some lines in glpi/inc/mailcollector.class.php. Specifically, I've commented out lines 1965 and 1966. Without this case in the switch statement, the default option is fired when returns the From header as the requester field. With this change I'm pulling all emails that hit the inbox that my IMAP receiver is polling. Again....I'm not in prod yet and would anticipate a permanent fix to this before I go to prod (if I don't dig further for the root cause myself....), but I also don't feel this is super-risky because I'm just not allowing the system to look for a reply-to header. Just wanted to offer up more of what I've discovered this evening. Thanks all! |
|
@raregtp Thanks for the insight! I had played around with the PHP myself, but not having used it ages and being very rusty, was making a lot of shots in the dark. I will look at disabling those lines too, as this may solve our issue temporarily. However, like you, I would hope for a permanent fix soon... |
|
Hi @raregtp , Can you attach to this issue a sample email (in .eml format) that cause the problem ? So we will be able to use it in unit tests. Regards |
|
Hi @cedric-anne I've attached a sample email (redacted) that I believe causes the issue (as you will notice, it does not have a Reply-To header). |
|
Thanks for this sample email. I successfully reproduce this problem on our test suite (see https://github.com/glpi-project/glpi/pull/7652/checks?check_run_id=857667428), so now we have to find a fix for it. |
|
Hi, Thanks for the update. Let me know if you need any more details in the meantime. |
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster
- Prevent exception on adresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster - Prevent exception when "Content-Transfer-Encoding" is not set; fixes glpi-project#7649
- Prevent exception on addresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster - Prevent exception when "Content-Transfer-Encoding" is not set; fixes glpi-project#7649
- Prevent exception on addresses parsing; fixes glpi-project#7643 - Correctly fetch additionnal headers that may be used in rules - Fix exclusion of mailer-daemon/postmaster - Prevent exception when "Content-Transfer-Encoding" is not set; fixes glpi-project#7649
|
#7652 does appear to have resolved this issue. Thanks! |
|
Yeah, this has fixed it for us too! |
Hi, Can you create another issue with the error trace and attach an example of email causing this issue ? Regards |
Describe the bug
Since upgrading our system to 9.5.0, we have discovered that our email receiver does not work as expected. On further investigation, it appears that it now cannot handle emails in which we do not have a Reply-To header.
This is the error we get when trying to receive emails.
It should be noted that we do have an In-Reply-To header. I would also like to note that it doesn't seem to handle emails where there is no To header (for example, all recipients are in the BCC header).
Page(s) URL
https://{GLPIHOST}/glpi/front/mailcollector.form.php
To reproduce
Set up a mail receiver.
Have an email with either no To header, or not Reply-To header in the inbox.
Attempt to retrieve the email.
Expected behavior
The email should be imported into GLPI.
Logs
Your GLPI setup (you can find it in Setup > General menu, System tab)
The text was updated successfully, but these errors were encountered: