Having the same issue on v1.12.5-88, but with the same setup: sending via Amazon SES to our mailbox hosted with Yandex.Mail for Domains. (Sending from a verified domain/email address is an Amazon SES requirement, so our only option is to include the sender info in the Reply-To header.)
Almost 6 years later, the issue is still not resolved, and this is the most helpful and relevant Google search result, so @ntozier, please don't "kill the zombie thread", at least not until the bug is fixed in the core code. (Here's the only commit to
class.mailfetch.php relevant to
Reply-To since 2015 that I found.) The purpose of this post is to confirm the issue still exists and is not resolved, bring the attention to it, add information on how to reproduce it, and restore the formatting of the proposed solution.
I confirmed the filter itself works and is in fact being triggered by adding an extra action - in my case, it was "Attach Canned Response". So this is definitely not the incorrect filter rules issue.
Many thanks to @zox for doing most of the research, and coming back with a solution. The forum software must have been migrated, and the code formatting was lost, but I have found it in the Web Archive.
Here's how to reproduce: insert this code right after
$raw_header = $this->getHeader($mid);.
// Dirty hack to workaround PHP bug in imap_headerinfo()
// Require the logging facility
$ost->logDebug('debugging reply_to', json_encode([
'$replytowa' => $replytowa->reply_to,
'$headerinfo' => $headerinfo->reply_to,
Check the logs at
/scp/logs.php to see both Reply-To values. Implementing the change proposed above (hot?)fixes the issue: use
$replytowa instead of
It was my opinion that's the issue -- but perhaps you know better than I, how the system actually works
To be fair, that looks unnecessarily rude, and the guy was actually right, after all. And the further irony is, it seems matching on
@ wasn't even his idea.
Either way, thanks for the great software!