User email notifications received if submitted by web, but not if submitted by email

sstillwell

Just installed osTicket 1.8.0.2 on Debian Squeeze running nginx. Email is being sent remotely via SMTP to a qmail toaster, and it's being handled via cron.Email is sending and receiving fine - I can send email to my support@domain.tld address and get a ticket created, and I get admin notification of the ticket.What doesn't happen is that the user doesn't get a notification that their ticket was created - that email has the ticket number that would allow them to log in and view status on the ticket.If that same user (same email address) creates a ticket through the web form, they get a notification email.Ideas?Scott

sstillwell

Oh, sorry - inbound email is being handled via IMAP polling.

ntozier

Have you checked that its enabled in Admin panel -> Settings -> Autoresponders?Are you using SMTP or PHPMail for outgoing? (If PHP Mail try changing using SMTP instead)See Admin panel -> Settings -> Emails -> Default Outgoing EmailandAdmin panel -> Emails -> your email -> SMTP Settings

sstillwell

As I said, I'm using SMTP. I looked at Autoresponders and didn't see any differentiation between tickets created by web or email, but I'll check again.

sstillwell

I'm not seeing any place that I can specify that emails get sent differently if a ticket is created by email rather than web form. I can specify if an email gets sent if a ticket gets created - that option is turned on. When I create a ticket via web form, the client notification email DOES get sent. If a user sends an email to the inbound email address (support @ domain dot tld) the email gets picked up, the ticket gets created, admin gets email notification, support team gets notification if I auto-assign, but the client that sent the initial email request does NOT get notification, and thus doesn't get the ticket number they need to be able to log in.If I'm missing something I don't know where it is. I'm using SMTP and IMAP, email seems to be going out and coming in as it should - with this one exception. When I respond to their ticket, they will get an email that has the necessary links for them to log in, as well as the ticket number, but from the user's standpoint their initial email just goes into a black hole with no auto response.Help? :)

ntozier

You haven't actually said if Admin panel -> Settings -> Autoresponder -> New Ticket is enabled.Are you auto assigning tickets to a department? If so have you checked Admin panel -> Staff -> Departments -> your department -> Auto Response Settings?Have you checked your spam filter for the missing email?Have you checked your email servers logs to see if the email ever got sent?Are you using ticket filters? If so have you checked Admin panel -> Manage -> Ticket filters -> your filters -> Ticket auto-response?

sstillwell

You haven't actually said if Admin panel -> Settings -> Autoresponder -> New Ticket is enabled.Yes I did - " I can specify if an email gets sent if a ticket gets created - that option is turned on. " Sorry I wasn't specific. All four auto responder settings are set to "Enabled".Are you auto assigning tickets to a department? If so have you checked Admin panel -> Staff -> Departments -> your department -> Auto Response Settings?The "Disable" options for sending email on the departments are NOT checked.Have you checked your spam filter for the missing email?Yes, I have. It's not there. I'm testing using my own email accounts (not the same as the email on the Staff assignments - another personal email address.Have you checked your email servers logs to see if the email ever got sent?Yes, I have. It wasn't. I built and maintain those servers (both web and email).Are you using ticket filters? If so have you checked Admin panel -> Manage -> Ticket filters -> your filters -> Ticket auto-response?No, I'm not using any filters.Once again, If I create a ticket using the web form, the email DOES get sent - if the settings were wrong that wouldn't happen. When I create a ticket from the SAME email account that I used on the web form, but create it by sending email to the support address, the ticket gets created but the email does NOT get sent, even though the staff emails get sent. That's a pretty specific test case. Hope that answers your questions specifically enough. Let me know.

ntozier

I'll bring this thread to the attention of the devs... but I am not able to replicate the behavior that you are reporting.

jared@osticket.com

Can you send me an example of one of the emails (with the headers) received into your system? Are the fields from the email otherwise handled correctly (email address, friendly name, subject, body (message), etc)?

sstillwell

Hmmm...I think we may be on to something...I tried a different email address for the client (a gmail account) and it worked. The email account that isn't working is an iCloud account - and on closer review I CAN see it coming in on the Submission queue from the web server and being accepted for relay (the server is a valid MX for the domain, and is set correctly in DNS for SPF and DKIM). It's heading back out and being accepted for delivery by Apple's servers...02-16 23 delivery 1406: success: User_and_password_not_set,_continuing_without_authentication./<REDACTED>_17.172.34.12_accepted_message./Remote_host_said.5.0_Ok,_envelope_id_<REDACTED>-smtpin004.mac.com/02-16 23 status: local 1/10 remote 0/10002-16 23 end msg 2033244It's never winding up in the spam mailbox or ANYWHERE in iCloud, which is REALLY annoying. They're killing the email silently for some reason. What's interesting is that if I log directly into that support email account and manually send an email to the same iCloud destination account - THAT email shows up.I'll see if I can get actual raw email with headers for both types of examples. The outbound email from osTicket doesn't seem to wind up in the sent items folder, so that one may be harder to come by.Thanks for staying with me on this...

sstillwell

Simplifying even more and just using the Diagnostic email rather than creating a support ticket - I still get the same behavior: sending to a gmail account works, but sending to iCloud results in it going away silently at Apple's end. Sending an email directly from that same outbound account is also accepted by Apple, but the email DOES get delivered.When I manually send the following email, it DOES get delivered.Received: from 192.168.79.254 (SquirrelMail authenticated user support@<REDACTED>) by <REDACTED> with HTTP; Mon, 17 Feb 2014 10 -0600Message-ID: <b87647dd806188363970d91010d3f90e.squirrel@<REDACTED>>Date: Mon, 17 Feb 2014 10 -0600Subject: Test messageFrom: support@<REDACTED>To: <REDACTED>@me.comUser-Agent: SquirrelMail/1.4.20-1.3.17MIME-Version: 1.0Content-Type: text/plain;charset=iso-8859-1Content-Transfer-Encoding: 8bitX-Priority: 3 (Normal)Importance: NormalPlease accept this for delivery - this IS a valid email regardless of whatyou may think, Apple!ScottNow, do we have a good way of getting the raw text of the emails osTicket is sending? It doesn't seem to capture anywhere. Ah, never mind, I'll just set up a "tap" and have it copy to another account.Delivered-To: scott@<REDACTED>Received: by 10.220.162.138 with SMTP id v10csp135380vcx; Mon, 17 Feb 2014 09 -0800 (PST)X-Received: by 10.182.113.195 with SMTP id ja3mr3167400obb.46.1392656979068; Mon, 17 Feb 2014 09 -0800 (PST)Return-Path: <support@<REDACTED>>Received: from mailhost.<REDACTED> (<REDACTED>. ) by mx.google.com with ESMTPS id e6si5390771oen.10.2014.02.17.09.09.38 for <scott@<REDACTED>> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 17 Feb 2014 09 -0800 (PST)Received-SPF: softfail (google.com: domain of transitioning support@<REDACTED> does not designate <REDACTED> as permitted sender) client-ip=<REDACTED>;Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning support@<REDACTED> does not designate <REDACTED> as permitted sender) smtp.mail=support@<REDACTED>Received: (qmail 11613 invoked by uid 89); 17 Feb 2014 17 -0000Received: by simscan 1.4.0 ppid: 11605, pid: 11608, t: 0.1467s scanners: attach: 1.4.0 clamav: 0.97.3/m/dReceived: from unknown (HELO localhost) (support@<REDACTED>@<REDACTED>) by mailhost.<REDACTED> with ESMTPA; 17 Feb 2014 17 -0000Content-Type: multipart/alternative; boundary="=_cca84295dc0199c97d15c4c1d0787b81"MIME-Version: 1.0From: "<REDACTED> Support" <support@<REDACTED>>To: <REDACTED>@me.comSubject: osTicket test emailDate: Mon, 17 Feb 2014 17 +0000Message-ID: <ycM5kbZEGg6.4-hV-support@<REDACTED>>X-Mailer: osTicket Mailer--=_cca84295dc0199c97d15c4c1d0787b81Content-Transfer-Encoding: base64Content-Type: text/plain; charset=utf-8dGVzdA==--=_cca84295dc0199c97d15c4c1d0787b81Content-Transfer-Encoding: base64Content-Type: text/html; charset=utf-8dGVzdA==--=_cca84295dc0199c97d15c4c1d0787b81--And there we see the problem (or you would if I didn't have to strip out IP addresses and such. The error is that my mail server sits behind a NAT firewall, and the outbound traffic doesn't leave on the same IP address that the INBOUND traffic comes in on (which is what's in the A record for the host). This makes a SPF policy failure. I've updated the SPF records to include that outbound IP address and will test again.Sorry for the fire drill - I will post again if it doesn't resolve, but I'm thinking it will.

ntozier

Please let us know how you make out. Good catch btw!

sstillwell

I tried again and got the same result. This time the raw email shows validated SPF - but Apple still throws it on the floor. It may be a DNS cacheing issue on their end - if so the problem will go away in a few days. If not...we're still left with figuring out what they don't like about that particular email, when a simpler, plainer text email goes through successfully with the same from and to addresses.Where I placed the tap on the support account and copied to another address I can see that the email IS going out. So...the email send mechanism in osTicket is working exactly as it should, the only possible fly in the ointment is if there is a problem with the headers or something that Apple doesn't like.Have I mentioned that I hate email? :)Scott

ntozier

I'll second that sentiment. :)

sstillwell

Solved - Apple was spam-filtering the emails. I got in touch with AppleCare and they bumped it up to senior engineers at iCloud - the reviewed the emails and then whitelisted the domain. All the emails that had been filtered were still there and cam flooding into my inbox in a burst.Argh again for email, but major kudos yet again for AppleCare. There's a reason their support is highly rated.Scott

ntozier

Well at least you got it all sorted out. :) I'm going to close this thread, please feel free to post again if you have another question.