Akeeba Ticket System is primarily designed as a helpdesk component where submitting new tickets and replying to tickets takes place on the site itself. This allows for intricate, time–saving features like the ones described in the earlier sections about custom fields and InstantSearch.
There are, however, many sites where the ticket workflow is best suited to be managed via email, e.g. there are very few categories (possibly even just one), there is only a small number of people managing tickets (possibly even just one), there are no custom fields, clients are expected to prefer sending an email over logging into the site and so on and so forth. Akeeba Ticket System makes it possible to cater for any combination of the following email–to–ticket workflows:
Support staff can reply to existing tickets by email.
Clients can reply to their existing tickets by email.
Clients can submit new tickets by email.
Guest users can submit new tickets by email.
These workflows are implemented through the Akeeba Ticket System - Fetch Email plugin and CRON jobs.
For this feature to work you will need to have one or more email addresses which will only be used by Akeeba Ticket System.
These email addresses cannot be used by one or more human user(s), other ticket systems (installed on your site, standalone, or third party services), or any other kind of automation. The simple and fairly obvious reason for that is that if anyone or anything else reads the email before Akeeba Ticket System does, then Akeeba Ticket System will be unable to read this email (since it's already read, therefore assumed already handled) and, as a result, will be unable to process the email it cannot read.
This behaviour obviously cannot change. If Akeeba Ticket System were to start handling read and/or deleted email you would end up with hundreds to thousands of duplicate tickets and/or ticket replies, one added every time Akeeba Ticket System's email fetch automation would execute. There would simply be no way to mark an email as already handled.
While this point is fairly obvious, especially in retrospect, it can easily be lost on an overworked integrator trying to figure out a migration from an existing ticket system or manual support email handling. We have seen this happening, hence this notice.
Email messages are far more limited than full blown websites. The entirety of the information you are receiving over an email message can be summed up like this: name and email address of the sender; subject; email body; attachments.
As a result the following features cannot possibly work over email:
Ticket custom fields, Ticket tags, User Tags, Time Spent. There is no reliable way of parsing free text into the structured format of these fields.
User information, avatar, total time spent, user groups, previous tickets shown next to each user's reply in a ticket thread. Obviously, these are features which can only be implemented on your site. While some of that information COULD be sent via email it becomes problematic when it comes to attachments, as will be discussed below.
InstantSearch. InstantSearch is designed to make search queries and display their results before the client submits their ticket. By definition, once we receive an email the client has already submitted their ticket. Therefore it makes no sense providing them with a link to search results.
Canned replies. These are snippets of text which can be inserted in your ticket reply as a Support Staff member. By definition, if you are using an email client application or a webmail site to send replies via email you do not have access to them.
Signatures. These are only displayed on the site, they are not included in the email message.
Moreover, receiving new tickets and/or ticket replies over email requires making sense of the subject and body of the email.
The subject is pretty straightforward... unless it contains any character which cannot be encoded in 7-bit ANSI. You see, the original email specification (RFC 822) was written back in 1982 and is in fact a standardization of the hodgepodge of message exchange protocols which sprang in the 1970s, back at the dawn of networked computers. Computers were not capable of displaying characters with diacritics beyond some very basic ones, let alone characters from different character sets like Cyrillic, Greek etc. There is a way to encode full Unicode characters in a way that is sent by email and most email clients support it. ATS will try to parse the subject using those standards and do its best to represent it as real Unicode information which can be stored in your site's database.
The body text is even more complicated. You see, email was designed to send short, plain text messages. Most of the email you see today is actually HTML email, i.e. an HTML document sent as an inline attachment, with or without an alternative, text–only representation. ATS will try its best to divine if the email is plain-text only (very popular among Linux and German users in particular), HTML–only or HTML–with–plain-text. If it's just plain text, ATS will convert it to a basic HTML representation since all ATS posts to tickets are HTML. This works for messages sent from the vast majority of mail clients but it all depends on whether the mail client uses the standard convention of attaching the subject as the first inline attachment in the message. Yes, there is no standard for that, just a convention.
The other problem is that every single image you include in a mail message, including inline images, is in fact an attachment. ATS will process all attachments as such, even if they are inline. This means that the email sender's user account needs to have the Attachments permission to allow these to be attached to their ticket. Furthermore, images anywhere in the documentnwill be processed as attachments — even if they are part of their signature. On top of that, for security reasons, ATS will NOT display attachment inline. Any inline attachments in mail messages are shown as broken images or empty text. This may make communication with clients problematic if they are using inline images to communicate something. You will have to figure out which one of their attachments corresponds to each inline image they reference in their ticket.
ATS will try to remove signatures from email. It understands HTML signatures following the Thunderbird and Microsoft standards, as well as plain text signatures preceded by a line consisting of only hyphens (with at least two hyphens present) and they are shorter than 10 lines of text. Other signatures may be inadvertently become part of the ticket post text itself.
ATS will try to not include the original message. This applies when the original message is quoted. The HTML quotation styles supported are basic blockquote, as well as the Thunderbird, Microsoft, and Apple conventions for quoting messages. For plain text messages, ATS assumes quotes messages have their lines start with a > character. ATS can only recognise quoted text as being the original message if it's a single block of quoted text between some non-quoted text and the end of the message / beginning of the signature.
The original quoted message will be included as-is in the following cases:
An unsupported quoting style is used, e.g. indentation instead of quotation.
There is a signature, but it is not recognized as such.
The user has replied below the quoted message.
There is non-quoted text between or after blocks of quoted text. In this case, ATS will deliberately NOT remove quoted text as it may indicate the client is replying to parts of the original message to provide context for each part of their response (“in-line posting”).
ATS may also include text added by the mail client before the quoted text such as "On 26/08/2025 John Q. Public wrote:". We have tried to make ATS recognise some of these lines added by Thunderbird, Microsoft mail clients, and Apple Mail in English, German, French, and Spanish and remove them. That said, these lines are not standardised, and there are many more language we can't possibly support so your mileage may vary.
Please note that these limitations are NOT unique to ATS. All email-based helpdesk systems suffer from them. Most commercial helpdesk systems don't even try to address any of the aforementioned limitations at all.
ATS needs to know which ticket a client is replying to. In the past, we were using a “Reply above this line” message with a specially-encoded ticket ID to address this issue. This didn't help any if the client simply deleted the entire text before starting their reply. ATS 5.4.1 and later versions use the References email header, automatically included in the replies by mail clients, to keep track of the ticket ID. In case this header is removed by the mail client, ATS falls back to reading the ticket ID from the email subject line.
Joomla 5.3 and later versions have a feature called Mail Template Layout. This automatically wraps the actual Mail Template with an HTML template to make the email "pretty". Unfortunately, the default Mail Template Layout supplied by Joomla is a DIV soup, making quoted replies virtually impossible with every HTML mail client we tried. Therefore, we strongly advise that you either disable Mail Template Layout altogether, or at least disable them for ATS' mail templates. When you make a new installation of ATS 5.4.1 or later, or use the button on ATS 5.4.1 or later will install ATS' default mail templates with the Mail View Templates feature DISABLED for them.
To disable Mail Template Layout altogether:
Go to your site's administrator.
Click on , Templates, Mail Templates.
Click on the button in the toolbar.
Set Mail Template Layout to Disabled.
Click on .
To disable Mail Template Layout only for ATS email:
Go to your site's administrator.
Click on , Templates, Mail Templates.
Click on the button in the toolbar.
Set Per Template Mail Settings to Yes.
Click on .
Filter the list by the Akeeba Ticket System extension.
Click on a mail template.
Go to its Options tab.
Set Mail Template Layout to Disabled.
Click on .
Repeat steps 7 through 10 for each ATS mail template.
If you are on a time constraint, this is the minimum list of mail templates you need to disable Mail Template Layout for:
Akeeba Ticket System: Post edited (admin)
Akeeba Ticket System: New private ticket (admin)
Akeeba Ticket System: Private ticket reply (admin)
Akeeba Ticket System: New public ticket (admin)
Akeeba Ticket System: Public ticket reply (admin)
Akeeba Ticket System: Post edited (user)
Akeeba Ticket System: New private ticket (user)
Akeeba Ticket System: Private ticket reply (user)
Akeeba Ticket System: New public ticket (user)
Akeeba Ticket System: Public ticket reply (user)
Finally, you need to set up CRON jobs for ATS to periodically check for email. This may be a bit frustrating in the sense that it is not only an additional administrative burden for you as a site owner but also confusing for the client who were they to visit your site would not see their new ticket or ticket reply appear immediately but only after the CRON job has run. Running the CRON jobs too often could bog down your server, running the CRON jobs too infrequently would make clients wonder if their ticket / reply didn't make it through and possibly resend it. Typically, having the CRON job run once every five minutes should be enough.
While you can use Joomla! Scheduled Tasks to check for new email, please be advised that the "Lazy Scheduling" option IS NOT going to work in any way that you or your clients would consider adequate. Email would only be received when there is traffic on your site. If someone submits a ticket in a period of very low or no traffic the scheduled task may never run. If you decide to use Joomla! Scheduled Tasks you MUST set up a CRON job to trigger Joomla! Scheduled Tasks' runner.
Generally speaking, receiving tickets or ticket replies by email is something that requires thought, preparation, and upkeep. We only recommend this on larger ATS installations deployed for a company or organisation in an intranet or extranet. It is also antithetical to the collection of structured information with custom fields, user assisting features such as InstaSearch etc. You really need to weigh in all those factors before deciding whether the user convenience of sending / replying to a ticket by email is worth the additional workload for you as a site administrator, and the support team.
Displayed in the Joomla! Plugin Manager as Akeeba Ticket System - Fetch Email
This plugin allows your site to retrieve email from a mail server and create new tickets or replies to existing tickets based on your settings. It makes the mailfetch CRON command available.
This plugin only provides the infrastructure required to retrieve emails but does not automate the process, i.e. publishing it is required byt NOT sufficient to retrieve emails.
You will need to create a CRON job, either using the CRON CLI script or the CRON URL. Please note that the System - Akeeba Ticket System reply by email plugin has been removed because it had inherent consistency issues when fetching email.
If you are creating a CRON job use the mailfetch CRON command to retrieve emails.
These are the parameters which allow users to reply or create new tickets by sending emails to your site. Please remember to enable the respective plugin or the CRON job script.
Starting with Akeeba Ticket System 3.2.0 we are no longer using the legacy PHP IMAP extension to retrieve and parse email because it has not been maintained since the late 2000's and is no longer up to the task. Instead, we are using the Horde IMAP library which is written in pure PHP and does not require any PHP extensions. It's also faster and much more reliable. Nothing changes from your perspective.
The only exception is if you are using Gmail / G Suite. Because of changes made by Google to their server we can no longer offer the old I am using GMail option and you can not keep on using Gmail / G Suite accounts over IMAP with regular password authentication either. This is NOT because of the library change explained above but because Google decided to discontinue support for a web standard. The reason we are now using the Horde library is that it's the only way we could support the only authentication method Google supports. It is complicated to set up but does work once set up.
When enabled allows users to reply to their tickets by email.
When enabled the email features (Reply by Email and Create Ticket by Email) are only available to managers (support staff).
This option can serve a secondary purpose, beyond the obvious. You can use it to do a “soft roll-out” of the email reception features, starting with the much smaller and more easily controlled group of support staff. Once you've ironed out any problems you can turn this option off and let all of your users to use email to reply to / create tickets on your Akeeba Ticket System installation.
When enabled allows users to create new tickets by emails. Obviously, the user needs to send the email from the email address they used to register on your site.
This is dangerous! A user with an auto-reply may cause an endless amount of tickets being created all the time. We strongly recommend NOT using this option.
When enabled Akeeba Ticket System will track the unique identifier of each email message it has processed to prevent double posting of tickets e.g. when an error occurs after a new ticket is created but before it's marked as read / deleted. This is recommended to be enabled on production sites.
If you change email providers or mailboxes this might cause new email to be dropped if the new email provider / mailbox uses the SAME unique IDs as the old one. In this case you will need to disable this option and enable the Delete after post creations option, documented below.
When enabled Akeeba Ticket System will try to retrieve the plain text version of the email and use it as the post content. If the user's mail client only sends an HTML version of the email this could cause empty tickets / replies to be created.
The category where the new tickets created by the "Create ticket by email" feature will be placed.
Your incoming mail server type (IMAP, POP3 or GMail).
If you are using a GMail / G Suite mail account please refer to the "GMail / G Suite Initial Configuration" section of this documentation.
The hostname or IP address of your mail server
The port of your mail server
If your server uses SSL set this to Yes
If your server uses TLS set both this to either When Available or Always and also set Use SSL to Yes
If you have enabled Use SSL and Use TLS select this option to have ATS verify the SSL certificates presented by your mail server. If the certificates are self-signed this WILL fail. We recommend using this option only when your mail server is using a commercial SSL certificate.
The username you use to connect to your incoming mail server. Usually this is either your email address or the part of your email address before the @ sign. Please consult your email provider.
The password you use to connect to your incoming mail server.
If you have an IMAP / GMail / G Suite mail server select the folder where the messages are stored. This is usually INBOX (all capital letters)
Only applies if you are using a GMail / G Suite mail account. Please refer to the "GMail / G Suite Initial Configuration" section of this documentation.
Only applies if you are using a GMail / G Suite mail account. Please refer to the "GMail / G Suite Initial Configuration" section of this documentation.
Only applies if you are using a GMail / G Suite mail account. Please refer to the "GMail / G Suite Initial Configuration" section of this documentation.
Only applies if you are using a GMail / G Suite mail account. Please refer to the "GMail / G Suite Initial Configuration" section of this documentation.
Only applies if you are using a GMail / G Suite mail account. Please refer to the "GMail / G Suite Initial Configuration" section of this documentation.
Should the retrieved email messages be deleted from the server after the post/ticket has been created? If this is set to No then the emails are only marked as read. If you set this option to No we strongly advise that you set Track email UID to Yes.