I've setup everything in my new install to use SMTP for email. Or, at least everything I can find. But the button for end users to receive an email link to check their ticket status still attempts to send via the php mail function. All other alerts go out fine via SMTP.

osTicket Version v1.11 (d4e240b) — Up to date
Web Server Software Apache/2.4.29 (Ubuntu)
MySQL Version 5.7.25
PHP Version 7.2.15-0ubuntu0.18.04.2

Not sure what button you are talking about.

Admin panel -> Emails -> Settings -> Default MTA?

What address is the alert coming from?
Have you checked that address in Admin panel -> Emails -> Emails to see how its configured?

Default MTA is set to the SMTP email address I've setup.

As for the button, if you go to the end-user portal and click Check Ticket Status it brings up a form where you enter the email and ticket number then click "Email Access Link". Clicking that button will generate two errors:

Error 1:
Unable to email via SMTP:smtpserveraddress:587 [email@domain.com] Failed to add recipient: @localhost [SMTP: Invalid response code received from server (code: 501, response: 5.1.3 Invalid address)]

Error 2:
Unable to email via php mail function: mail() returned failure

On error 1, I have no idea why its trying to add @localhost as a recipient. On error 2, I can't figure out why its using php. All other alerts and notifications go out just fine. On the ticket I was just testing the end user receives the notice a ticket has been created, agents get the alert, users receive updates from agents with no problem. I thought it might be non-ticket related emails, but I can send password reset links to agents with no issues.

    I also have the same problem, the email does not arrive with the link, and it gives me exactly the same errors

    looks like your email settings are incorrect, and like @ntozier saying Default MTA, you might still have set to Local PHP function
    Take screenshots of screen with email settings details

    Does anyone have a solution to this problem?

    In addition to the errors mentioned by something_amusing, In gmail spam, the following message appears

    A message that you sent contained no recipient addresses, and therefore no
    delivery could be attempted.

    ------ This is a copy of your message, including all the headers. ------

    To:
    Subject: Chamado [#190011] Link
    X-PHP-Script:

    To reiterate, the default MTA is not set to local PHP, it is set to the SMTP email we have setup. I'm attaching a screenshot of that. And no, we aren't using Gmail. Its an O365 mailbox if that matters. And again, all other emails except this one go out just fine.

    @something_amusing
    [ignoring everything in this thread that you didn't post]

    You are getting two errors.
    The first says Unable to email via SMTP:smtpserveraddress:587 [email@domain.com] Failed to add recipient: @localhost [SMTP: Invalid response code received from server (code: 501, response: 5.1.3 Invalid address)]

    The second says Unable to email via php mail function: mail() returned failure

    osTicket tries to send an email via SMTP: from email@domain.com to @localhost. Since @localhost is not a valid email address it fails completely.

    Since it failed it attempts to fail back to phpmail to send the email. Which once again fails probably for the same reason.

    I'm curious why your User has an email address of @localhost instead of well an email address.

      ntozier honestly I thought the @localhost was just a mistake or part of the error. It doesn't matter what email I entered, it always showed that. And the users are successfully created and able to submit tickets. I'll run some more tests and see if I can isolate anything.

      ntozier So, in Agent > User, I can see the user's email. So the system knows their email. And when using the link the user is entering their email along with the ticket number. I can't tell where its getting @localhost from as the email address. Any logging I can turn on to see where that is coming from?

      The only ways that I can think of that might do something like this would be if someone modified the source.

        ntozier it's a fresh install on a fresh Ubuntu image. Nothing customized yet. I'm the only one with access to the server.

        Yes, I used the download from the website. What is develop-next? Is that the release candidate? Assuming so, is there something in particular in that release that would fix this?

        7 days later

        I had the same Problem.
        Error: Failed to add recipient: @localhost [SMTP: Invalid response code received from server
        (code: 550, response: Requested action not taken: mailbox unavailable)].

        So I checked the source code and saw that the $recipient Variable in the addTo- function in class.mailer.php doesn´t transfer an E-Mail-Adress over the Object(User) and the Object (Enduser). I only added the getEmail-function like this: $mime->addTo($recipient->getEmail().""); and it´s working. Could you please check if this change is correct or is there a better solution?

        osTicket-Version v1.11 (d4e240b) — Aktuell
        Server-Software Apache/2.4.18 (Ubuntu)
        MySQL-Version 5.7.25
        PHP-Version 5.6.40-6+ubuntu16.04.1+deb.sury.org+3

          Same issue
          osTicket v1.11 (d4e240b)
          Web Server Apache/2.4.6 (CentOS) PHP/7.0.33
          MySQL 5.5.60
          PHP 7.0.33

          All mail goes well, but if i send a "check status mail" i got two errors:

          • Unable to email via SMTP:mail.xxx.com:25 [user_name] Failed to add recipient: @localhost [SMTP: Invalid response code received from server (code: 501, response: 5.5.4 Invalid Address)]

          • php: mail() returned failure

          1.12 has been released, please update and see if you still have the problem. 1.11 is no longer supported because of a security issue that was found.

          Patrick_V Actually last night we made a slightly different change. It was decided that all users will login with their Active Directory login to view tickets, so we just redirected that page over to the login page and bypassed this issue altogether. Kinda wish we hadn't so I could test that. But thank you.