Everything looks correct.I do not have an idea what's going wrong?If @[deleted] also has not one, I guess there is still the option to try an upgrade to the latest version. Maybe that helps - otherwise I'd suggest that @[deleted] could point that thread to the devs.

May be you can give a clue where in the code the structure $info; should be populated with reply-to email. I've looked through the code but was not able to find anything. I am trying to find what might cuase this behaviour.

Sorry, looked at the code, but since I am not so deep into it, so I can't really tell you / have an answer to your question.

The email that is displayed there is not the reply-to address of the incoming email.  It's the email address that the User entered as their email address when they signed up for an account, or created their first ticket.

Your filter rules seems incorrect to me - I'll recommend matching only on User-Information / Email address. e.g Email equals office-message@yourdomain.com with the action of use reply-to email. It will only be applicable to becoming emails from that particular email and with a reply-to address. 

Filter is correct, I've checked -it works for everything else but reply-to field. I've set as you recommended - no luck.I've investigated further and here is what I found:Filters are triggered upon ticket creation, in particular in this function (file class.ticket.php):        try {            // Make sure the email address is not banned            if (TicketFilter:($vars)) {                throw new RejectedException(Banlist:(), $vars);            }            // Init ticket filters...             $ticket_filter = new TicketFilter($origin, $vars);            $ticket_filter->apply($vars);        }I've checked what is inside $vars and it appears to be that the info there is incorrect:    => offline-messages    => offline-messages@example.com    => Сообщение с сайта mysite.com от zox@woohoo.com    => <0000014ebb560a02-27c22e41-9d2c-41dd-afe2-e66ee89f004d-000000@eu-west-1.amazonses.com>    => Received: from mxfront6h.mail.yandex.net ()    by mxfront6h.mail.yandex.net with LMTP id zDFeScNB    for <support@support.mysite.com>; Thu, 23 Jul 2015 17 +0300Received: from a6-146.smtp-out.eu-west-1.amazonses.com (a6-146.smtp-out.eu-west-1.amazonses.com )    by mxfront6h.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id XD43CFDAP7-YG3W7KZ4;    Thu, 23 Jul 2015 17 +0300    (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))    (Client certificate not present)X-Yandex-Front: mxfront6h.mail.yandex.netX-Yandex-TimeMark: 1437662056Authentication-Results: mxfront6h.mail.yandex.net; spf=pass (mxfront6h.mail.yandex.net: domain of eu-west-1.amazonses.com designates 54.240.6.146 as permitted sender) smtp.mail=0000014ebb560a02-27c22e41-9d2c-41dd-afe2-e66ee89f004d-000000@eu-west-1.amazonses.com; dkim=pass header.i=@amazonses.comX-Yandex-Spam: 1DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;    s=uku4taia5b5tsbglxyj6zym32efj7xqv; d=amazonses.com; t=1437662055;    h=Subject-To-Type-Transfer-Encoding-Version-ID-ID;    bh=oGX5Nhl8W0GaFsa+DG3OSfXhsj2Cige5dUcMsNF6Mv0=;    b=AKw+7b8lTqS+zaufmskAH5Uti9HFcKYE0SD4cK5HNZtKDJEbP2y7sGMimucNefUJ    ZnmO0BDWWLZqQ/zoVkHE93tNIRcoYwUqBT658XUoAMr5FrG+H3KOn/0S7+nTMzqcHpb    xSnT9ROD1Yif1qUHcxPtVD6eCt3NbaUtjoPAfJq0=DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;    s=q2kvnf6wdn3cucoh6u6jhjwbdr2uacee; d=example.com; t=1437662055;    h=Subject-To-Type-Transfer-Encoding-Version-ID;    bh=oGX5Nhl8W0GaFsa+DG3OSfXhsj2Cige5dUcMsNF6Mv0=;    b=WSED8kQ1s2GjGdlBubMIPM4PbeDfQnq8aBAgCdQ5NIvT44GYy8NbhBMg9Swft9dG    2vhQLB45Xj6a6M8K+FWS3xRvrdHCoCDBFbRrlN8rOG1xABno0yhZ+z42cEe+50m1H1Y    N3kcZF9SStWjtBYYV6ujyESK4RFtfZHBgg6ZPNGs=Subject: =?utf-8?Q?=D0=A1=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5=20?= =?utf-8?Q?=D1=81=20=D1=81=D0=B0=D0=B9=D1=82=D0=B0=20mysite.com=20?= =?utf-8?Q?=D0=BE=D1=82=20zox@woohoo.com?=From: offline-messages@example.comTo: support@support.mysite.comReply-To: zox@woohoo.comDate: Thu, 23 Jul 2015 14 +0000Content-Type: text/plain; charset=utf-8Content-Transfer-Encoding: quoted-printableContent-Disposition: inlineMIME-Version: 1.0Message-ID: <0000014ebb560a02-27c22e41-9d2c-41dd-afe2-e66ee89f004d-000000@eu-west-1.amazonses.com>X-SES-Outgoing: 2015.07.23-54.240.6.146Feedback-ID: 1.eu-west-1.ikBUQ8ihPSKu4AuEkmpbPR22urTnt57H+4c3sJWhOQ8=Return-Path: 0000014ebb560a02-27c22e41-9d2c-41dd-afe2-e66ee89f004d-000000@eu-west-1.amazonses.comX-Yandex-Forward: 94f75f0ddb54744ce8e4df2939e71f50    =>     =>     => offline-messages@example.com    =>     => Array        (        )    => 4    => 4    => ArrayObject Object        (            => Array                (                    =>                 )        )    => TextThreadBody Object        (            => Вам пришло сообщение с сайта mysite.com!....So in spite the fact that header has correct reply to info, $vars variable is populated with frong info.Do you have any ideas how to fix it?

@[deleted] - If this particular filter is NOT working then how do you figure it's correct? We use reply-to feature and it works.

@[deleted] - Easy - in the filter I set assign ticket to particular staff member and set reply-to email as requesters address. After this I see that ticket is indeed assigned to particular staff member - so filter itself works.However it does not change email. I've added debug print functions in the php classes to track down where the problem starts.And I have a question to those that have this reply-to functionality working - what PHP version do you use?Mine is PHP 5.6.11It looks like the cause is in the built in function imap_headerinfo so may be in different PHP version it works differently.

I think you're overcomplicating it --  my point was, based on the image you posted, you seem to be matching on reply-to header (including @ sign on name) to use reply-to header.  When filter action includes change of email (use reply-to for example) it starts the filtering loop all over again to apply the new criteria.  It was my opinion that's the issue -- but perhaps you know better than I, how the system actually works.Cheers,

  • aexl replied to this.

    @[deleted] - and what is the version of PHP on your osticket server?

    JFYI, finally I found w\aproblem as I posted before is in imap_headerinfoSo in order to fix it I've done following modifications (green stands for added lines and yellow for modified ) in class.mailfetch.php:    function getHeaderInfo($mid) {        if(!($headerinfo=imap_headerinfo($this->mbox, $mid)) || !$headerinfo->from)            return null;        $raw_header = $this->getHeader($mid);        // Dirty hack to workaround PHP bug in imap_headerinfo()         $replytowa=imap_rfc822_parse_headers($raw_header);        $info = array(            'raw_header' => &$raw_header,            'headers' => $headerinfo,            'decoder' => $this,            'type' => $this->getMimeType($headerinfo),        );        Signal:('mail.decoded', $this, $info);        $sender=$headerinfo->from;        //Just what we need...        $header=array('name'  => $this->mime_decode(@$sender->personal),                      'email'  => trim(strtolower($sender->mailbox).'@'.$sender->host),                      'subject'=> $this->mime_decode(@$headerinfo->subject),                      'mid'    => trim(@$headerinfo->message_id),                      'header' => $raw_header,                      'in-reply-to' => $headerinfo->in_reply_to,                      'references' => $headerinfo->references,                      );        if ($replyto = $replytowa->reply_to) {            $header = $replyto->mailbox.'@'.$replyto->host;            $header = $replyto->personal;        }

    Great you found a solution and I guess @[deleted] can decide if it's necessary to include a clean workaround for that possible PHP bug.

    5 months later

    Hello everyone,today we deployed, after testing, OsTicket. And it turned out, we face the same problem, as @[deleted] described. I've tried filtering, like @[deleted], and nothing helped.I run the latest stable version.I'd like to ask you what can be done to fix this "reply-to" issue?

    @[deleted] Isn't the fix posted two comments above yours?

    @[deleted] - I am not an expert in editing code, so It would be cool if this was fixed by the official OsTicket team. I do not want to make any manual edits.

    5 years later

    Hi everyone,

    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()
$replytowa=imap_rfc822_parse_headers($raw_header);
// Require the logging facility
global $ost;
$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 $headerinfo here.

    Lastly, peter

    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!

      One more heads up: had to change this line to decode the Reply-To name, otherwise it showed Base64-encoded gibberish.

      $header['reply-to-name'] = mb_decode_mimeheader($replyto[0]->personal);

      (Source)

      Write a Reply...