Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

System works but various SMTP response codes in emails logs.

The system works and I do get notification emails (so is the user).
However, if I look into the system logs, I see logs entry's, have a look especially at the SMTP response codes.
The SMTP error codes below are from 4 different log messages. But all start with the same "failed to set sender" issue.

Unable to email via []
Failed to set sender:
[SMTP: Invalid response code received from server (code: 554, response: Security failure)]
[SMTP: Invalid response code received from server (code: -1, response: D$Hڽ
[SMTP: Invalid response code received from server (code: -1, response: 2B
[SMTP: Invalid response code received from server (code: -1, response:

The security failure (happens more often) I would understand, if the pass was wrong, but it isn't.
As you can see also, on the other response codes (from other errors), the closing tags are missing, no ) and ] at the end visible in the logs.
Seems to me something buggy is going on there, especailly if I look at those strange ascii codes.
I use the pipe system to do my email sending, which works in fact fine, except for those logs.

Now I got 2 questions.
1.) Is there any way I can fix this so these errors are not in the logs anymore? Because they shouldn't because everything is working fine.
2.) I would like to keep using the pipe system, but send the ticket notification to another address at the same time as backup, how can I do this?


  • edited June 2016
    You have not provided us with enough information to assist you.  Please help us to help you by reading and following the posting guidelines located in this thread:  Please read before requesting assistance.  The more information you give us the better we will be able to assist you. Thank you.

    1.  Other than the 554 I would suspect a problem with the mail server based on the incomplete errors being returned.  554 means that the email server is saying that there is no valid PTR for that email address [and refused to send it].  PTR records are a DNS entry that resolves the IP address to a domain/hostname.  An A record should exist for every PTR.

    2. Piping is a *NIX only mail delivery option on your mail server.  You would have to change the configuration of your mail server.  This does not have anything to do with osTicket.
  • Oeps, I'm sorry.
    I'm using SMTP to send mail from Osticket so I'm using authentication.
    This is on a shared hosting server and I'm the administrator. On a shared hosting server there should only be 1 PTR record pointing to the main ip which mail is being send from, which in DNS should be the helo hostname used by the mailserver.
    You can be assured that the PTR record and DNS record is setup correctly for several years.

    My OS is Linux Centos 6.x with kernel 2.6.32-642.1.1.el6.x86_64.
    Php version 5.6.22.
    To be more explicit, the Directadmin control panel is being used on the server.
    For email Exim 4.87 #2 is used.

    1.) The 554 notice can have more then 1 cause. In this case, looking at the response code, it looks like an authentication issue. Which does in fact should not exist because everything is working fine and mails are send.
    In any case my DNS records and PTR record is in perfect order.
    It looks the me that the "failed to set sender" is causing these issues. This would give me the impression that for some reason Osticket is not able to set the sender email address. Which is again strange because mail is being send with the correct sender address.

    2.) I've found a workaround by adding another staff member and sending the notification email to that email address, so this is no issue anymore, so the 2nd question is solved.
  • "You can be assured that the PTR record and DNS record is setup correctly for several years."

    So all your clients do not have external email addresses?
  • edited June 2016
    I'm sorry, but are you a hosting provider? If yes, I would really check how PTR works and why you should not use multiple PTR records on a single shared ip.
    For mail delivery your MX record must point to a single A record, and your PRT record must resolve to a single A record.
    As you can read there and on multiple places on the internet, it can cause issues, because only 1 ip and  1 hostname is sending out the mail (helo), so no need and even bad practice to use multiple PTR's.
  • Are you saying the email works sending to one Agent or User but not another?
  • @Richard63 you did not answer my question.
  • edited June 2016
    @NTozier: I thought you were stating a retorical question.
    All customers have their own domain names on the server, with which they can create their own email addresses.
    They are some customers who have office365 email addresses if that's what you mean by "external email addresses". Those require some extra dns settings.

    Or do you mean that customers are using external email addresses like gmail or hotmail or from their own provider to send tickets to Osticket? That happens too and also does not create any issues in sending or receiving mails.

    However, in that case do not understand the relation to my PTR or DNS records for my server. My server sends mail to *any* provider without any issues. All anti-spam and dns checks you can think of give 100% ok values too.
    If this is not what you mean, please explain your question, I might have misunderstood it since I'm not English.

    @Buck_rogers: No I'm saying email is send like it should be and arrives perfectly at the agent's and staff's email addresses and the customers email address (even if it's a gmail or other external email address). The only thing happening is that it generates these strange response codes including strange characters in the Osticket system log.

  • Anybody an idea about this? It's months without a comment....
  • Looks like an SSL issue again, same which happened in 2012, like this:

    TLS error on connection from [64.100.xx.xx]:34111 (SSL_accept): error:00000000:lib(0):func(0):reason(0)

    TLS client disconnected cleanly (rejected our certificate?)

    This was fixed by disabling a check by default. It looks like in spite of that fix, the issue is occuring again.
Sign In or Register to comment.