email piping broke after server migration

[lbeachmike]

I migrated WHMCS from one server to another server configured with an identical environment.

After migration, an email sent to support will show in the logs that it was imported successfully, but it will import just a blank email to the wrong department.

The pipe command is identical on both servers.  The cpanel transfer tool was used to transfer the site.  I've transferred this WHMCS between servers before without issue.  There were no errors associated with the transfer.  Everything else works normally.

Any ideas?

Thanks.

[Remitur]

What do you find in Support Ticket Mail Import Log ( /admin/systemmailimportlog.php ) ?

There you can find the message imported, and so you can understand if it's a POP importing error, or some kind of post-processing error (= during the process to convert an email message to a ticket)

 

[lbeachmike]

WHMCS was perfectly happy reporting successful imports despite blank emails that all were assigned to the same department.

This turned out to be an Exim configuration issue that I am trying to better understand.

In a nutshell, the error in the mail delivery logs that led to solving it was -

discover_sender_information failed to set the from header rewrite for email@address.com

it was solved by turning off the 'From: header rewrite' feature mentioned in update #28 of the below thread -

https://forums.cpanel.net/threads/spam-email-from-self.635073/page-2

I believe the issue was related to using have this header rewrite feature active + DNS forwarding, but that's not yet clear.

The feature in Exim Basic Config is this one -

EXPERIMENTAL: Rewrite From: header to match actual sender -

If you enabled this option, the From: header will be rewritten to be the email address of the actual message sender. If you choose the "remote" option, only messages that are being sent to remote destinations will be affected.

 

Hope this helps somebody out.

[lbeachmike]

Not sure if I can edit my previous post.  After some further testing, it appears that it was simply the Exim restart (and not the parameter change) that actually solved this issue.