Symptoms: If a customer goes to the public side of the request portal and puts in a ticket, I get an email notice, and so do they. However, if a customer emails their ticket to helpdesk@, I get an email notice, but they do not get a confirmation email, leading them to call and ask if we got it. :-/I've checked the exchange server logs and I can see where my emails are sent to me, but their emails are not sent to them.Pertinent details, as requested:osTicket version: 1.8-git (?) (I installed from a Git Clone as suggested in the README.txt document a week or so ago, so it should be 1.9.5.1)PHP Error log entries or displayed errors. (you of course may remove any identifying information):I sent an email to helpdesk@ from a customer email address. From the time I hit send on their end to the time I received an email in my inbox here (~ 1 min), I observed no errors in error.log. It is however throwing this error whenever an agent goes to /scp/tickets.php: PHP Fatal error:  Uncaught exception 'Exception' with message 'hasSpecialSearch: Call to undefined function' in {webroot}/requests/include/class.forms.php\nStack trace:\n#0 {webroot}/requests/include/staff/tickets.inc.php(665): FormField->__call('hasSpecialSearc...', Array)\n#1 {webroot}/requests/include/staff/tickets.inc.php(665): TextboxField->hasSpecialSearch()\n#2 {webroot}/requests/scp/tickets.php(492): require_once('{webroot}...')\n#3 {main}\n  thrown in {webroot}/requests/include/class.forms.php on line 454, referer: http://{website}/requests/scp/index.phpMail Sending: phpMail functions or SMTP: I'm using an internal, anonymous SMTP relay into my exchange server, as I understand Microsoft is doing something funny with Base64 encoding that causes Base64 encoded emails to appear blank if it isn't the original mail handler.Mail Fetching/Receiving: Mail fetching is enabled under Admin -> Settings -> Emails, but Fetch on auto-cron is unchecked. Again, I'm using the pipe method to receive emails.PHP version: Here's direct from the CLI:PHP 5.3.3 (cli) (built: Oct 30 2014 20)Copyright (c) 1997-2010 The PHP GroupZend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies    with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend TechnologiesOperating System: CentOS v6 64-bit running kernel 2.6.32-504.8.1Client or Staff side of the UI: Client side, as in, my customers are who notice the issue.The location - the url or what your clicking on that is causing the problem: This only happens when customers email their request in.

Attached are some screenshots that may help those more knowledgeable than I on this issue. :-)

Looks like our comments crossed paths over the interwebz. See the above comment I posted for screenshots and let me know if that gives you any other clues as to where the problem could be?

ntozier,Ok, I went to osticket.com/downloads and grabbed 1.9.5.1, backed up my requests directory, and then replaced code. I think I ended up rolling back (?) because a few things are now missing that used to be there. Regardless, I should be on the official, stable 1.9.5.1 version now.Also, I'm already using SMTP instead of PHPMail. See attached. :-)Thanks in advance! :-)

Hi ntozier,Sorry, but it appears the problem still exists. Here's what I did this morning to test it:I'm at a customer site today, so I opened up email on their administrator account and sent an email to helpdesk@ at 10 AM. Then I walked away to work on an issue here.When I came back, I had no reply message in the administrator inbox here, but looking at my email account (@ in the logs) I had two messages: One sent to the administrator account on osTicket, and the other sent to me because I'm a member of the support team for the "Ticket Dispatch" department.This prompted me to go look at the Exchange message tracking logs. Since osTicket sends direct via SMTP to the exchange server and does not send via phpMail through postfix on the web server, this is the only place this should be tracked. For reference, I used the following Exchange PowerShell command to locate any instances of the email going out: C:\>get-messagetrackinglog -EventID SEND -Sender "helpdesk@" -Start "3/11/2015 9" -End "3/11/2015 23" -resultsize unlimited -MessageSubject "962614"| select-object sender, timestamp, messagesubject, {$_.recipients} | export-csv "c:\sentmail.csv"The ticket number generated was 962614, which is why I'm filtering for that above.Below is the output of the csv file that came back. It appears that it never sent an email back to the originating email address.#TYPE Selected.Microsoft.Exchange.Management.TransportLogSearchTasks.MessageTrackingEvent"Sender","Timestamp","MessageSubject","$_.recipients""helpdesk@","3/11/2015 10 AM","Support #962614 Created | Cust: Ticket Dispatch | User: Administrator | Subj: Test at 1008","@ @""helpdesk@","3/11/2015 10 AM","Support #962614 Created | Cust: Ticket Dispatch | User: Administrator | Subj: Test at 1008","@""helpdesk@","3/11/2015 10 AM","Support #962614 Created | Cust: Ticket Dispatch | User: Administrator | Subj: Test at 1008","@""helpdesk@","3/11/2015 10 AM","Support #962614 Created | Cust: Ticket Dispatch | User: Administrator | Subj: Test at 1008","@""helpdesk@","3/11/2015 10 AM","Support #962614 Created | Cust: Ticket Dispatch | User: Administrator | Subj: Test at 1008","@"Thoughts? Is this a bug in the pipe.php (or other) code?Thanks in advance!

ericstrelow,That was the winner! It was exchange, and your suggestion to tail out /var/log/maillog led me right to it.To answer your question, YES, I was using a distribution group on the exchange server that forwarded internally to an alias on the web server, referencing pipe.php in the /etc/aliases file.Looking in maillog, the message would come in as being from helpdesk@ instead of the original email address it was sent from.So, to fix this, I created a mailbox on the exchange server for helpdesk@ and enabled the IMAP auto-fetch via a cron job. I tested it and voila, a response email comes back to the original person sending the message.I'm a little bummed that I don't get to use pipe.php, because, well, that's ingenious. But it's a small price to pay for having a working solution!Thanks to both you and ntozier for all your help!