Hi,
today I updated our osTicket installation, but I run into a problem. Everything works except the creation of a ticket by mail. I can create a ticket in the web frontend. If I reply to a ticket by mail, my answer is attached to the ticket (so the mail system works). But whenever I just write a new mail to our mail address, nothing happens.

The log doesn't show anything besides the messages for user logins and the cron job. The server log also shows no errors. Is there any way to create a detailed log of what the system exactly does and where it stops? The system log is already set to Test.

Thank you!

    vitweb

    Check the _email_account table and look at the last_error column to see if there are any auth errors.

    Cheers.

      vitweb

      Did you confirm fetching is enabled at the email level (Admin Panel > Emails > Emails > click the email > Remote Mailbox > Status) and global level (Admin Panel > Emails > Settings > Email Fetching)? Did you also ensure your cron job was updated to reflect the new PHP version?

      Cheers.

        KevinTheJedi

        is enabled at the email level

        It is active.

        and global level

        Is also active.

        Did you also ensure your cron job was updated to reflect the new PHP version?

        The Cronjob was introduced only after the update of osTicket. It was set up to use auto-cron before. New tickets didn't work with auto-cron either. Answering mails of existing tickets does work with auto-cron and the new cronjob as well so I'm positive that neither the Cronjobs nor the mail server settings are causing the issue. It is only mails without a ticket number in the subject that do not get processed by osTicket.

        I guess it would be helpful to track which mails osTicket does fetch and what it does with them. Is there a way to do that?

        KevinTheJedi
        I'm one step further. I got access to the mailbox that we use for the ticket system. When I send a mail to this address it shows up in the inbox and disappears after the Cronjob has been executed. So apparently osTicket does fetch the mail but just doesn't create a new ticket.

        Edit: Problem solved! After digging into the database I realised that the tickets DO get created. But they get the wrong department ID and don't show up in the frontend because of that. There is a second department configured that we no longer use (at least at the moment) so noone could see them.

        I checked the config for the mail addresses, the correct department was selected. The issue was laying within the mail address. Our mail addresses always get an alias address with another domain (or maybe the addresses we use are actually the aliases, I don't know). The configured address was the one with the other domain so osTicket always placed the incoming mails in the first department it could find because the mail address did not match.

        Maybe it would be helpful to add a second field to the configuration where we can add alias addresses that the system also checks?

        Thanks again for your help!

          Based on your description, I tried sending an email directly to my main mailbox of the ticketing system, which can create a new ticket independently.

          The following command is used on my server /etc/crontab file

          */2 * * * * my_webserver_user /usr/bin/php /var/www/html/osticket/upload/api/cron.php

          osTicket Version: 1.18.1
          Web Server: Apache2
          PHP version: 8.1
          Database: MariaDB

            Jsezze

            Thank you! I was able to solve the problem. It was a combination of a configuration issue and our mailserver setup.

            vitweb Problem solved! After digging into the database I realised that the tickets DO get created. But they get the wrong department ID and don't show up in the frontend because of that. There is a second department configured that we no longer use (at least at the moment) so noone could see them.

            I checked the config for the mail addresses, the correct department was selected. The issue was laying within the mail address. Our mail addresses always get an alias address with another domain (or maybe the addresses we use are actually the aliases, I don't know). The configured address was the one with the other domain so osTicket always placed the incoming mails in the first department it could find because the mail address did not match.

            Maybe it would be helpful to add a second field to the configuration where we can add alias addresses that the system also checks?

            Write a Reply...