7.2. Receiving emails

From open-support.info

Mail accounts configured via the OTRS GUI

OTRS is able to receive emails from POP3, POP3S, IMAP, and IMAPS mail accounts.

Configure your mail accounts via the PostMaster Mail Accounts link on the Admin page.

If a new mail account is to be created (see Figure 7.1 below), then it's mail server name, login name and password must be specified. Also, you need to select the mail server type, which can be POP3, POP3S, IMAP or IMAPS. If you don't see your server type available as an option, the required Perl modules are missing on your system. In that case, please refer to "Installation of Perl modules required for OTRS" for instructions.

Figure 7.1. Adding a mail account.

If you select Yes for the value of the Trusted option, any X-OTRS headers attached to an incoming message are evaluated and executed. Because the X-OTRS header can execute some actions in the ticket system, you should set the Trusted option to Yes only for known senders. X-OTRS-Headers are used by the filter module in OTRS. The X-OTRS headers are explained in this table in more detail. Any postmaster filter rules created are executed, irrespective of the Trusted option's setting.

The distribution of incoming messages can be controlled if they need to be sorted by queue or by the content of the "To:" field. For the Dispatching field, if "Dispatching by selected queue" is selected, all incoming messages will be sorted into the specified queue. The address where the mail was sent to is disregarded in this case. If "Dispatching by email To: field" is selected, the system checks if a queue is linked with the address in the To: field of the incoming mail. You can link an address to a queue in the E-mail address management section of the Admin page. If the address in the To: field is linked with a queue, the new message will be sorted into the linked queue. If no link is found between the address in the To: field and any queue, then the message flows into the "Raw" queue in the system, which is the PostmasterDefaultQueue after a default installation.

All data for the mail accounts are saved in the OTRS database. The otrs.PostMasterMailbox.pl script, which is located in the bin directory of your OTRS installation, uses the settings in the database and fetches the mail. You can execute ./bin/otrs.PostMasterMailbox.pl manually to check if all your mail settings are working properly.

On a normal installation, the mail will be fetched every 10 minutes by the postmaster_mailbox cron job. For further information about modifying cron jobs, please refer to the "Setting up the cron jobs for OTRS" section.

When fetching mail, OTRS deletes the mail from the POP or IMAP server. There is no option to also keep a copy on the server. If you want to retain a copy on the server, you should create forwarding rules on your mail server. Please consult your mail server documentation for details.

Via command line program and procmail (otrs.PostMaster.pl)

If you cannot use mail accounts to get the email into OTRS, the command line program bin/otrs.PostMaster.pl might be a way around the problem. It takes the mails via STDIN and pipes them directly into OTRS. That means email will be available in your OTRS system if the MDA (mail delivery agent, e.g. procmail) executes this program.

To test bin/otrs.PostMaster.pl without an MDA, execute the command of the Script 7.1.

linux:/opt/otrs# cd bin
linux:/opt/otrs/bin# cat ../doc/sample_mails/test-email-1.box | ./otrs.PostMaster.pl
linux:/opt/otrs/bin#

If the email is shown in the QueueView, then your setup is working. Procmail is a very common e-mail filter in Linux environments. It is installed on most systems. If not, have a look at the procmail homepage.

To configure procmail for OTRS (based upon a procmail configured MTA such as sendmail, postfix, exim or qmail), use the ~otrs/.procmailrc.dist file and copy it to .procmailrc and add the lines of the Script 7.2.

SYS_HOME=$HOME
PATH=/bin:/usr/bin:/usr/local/bin
# --
# Pipe all email into the PostMaster process.
# --
:0 :
| $SYS_HOME/bin/otrs.PostMaster.pl

All email sent to the local OTRS user will be piped into bin/otrs.PostMaster.pl and then shown in your QueueView.

Fetching emails via POP3 or IMAP and fetchmail for otrs.PostMaster.pl

In order to get email from your mail server, via a POP3 or IMAP mailbox, to the OTRS machine/local OTRS account and to procmail, use fetchmail.

A working SMTP configuration on the OTRS machine is required.

You can use the .fetchmailrc.dist in the home directory of OTRS and copy it to .fetchmailrc. Modfiy/change it for your needs (see the Example 7-1 below).

 #poll (mailserver) protocol POP3 user (user) password (password) is (localuser)
 poll mail.example.com protocol POP3 user joe password mama is otrs

Don't forget to set the .fetchmailrc to 710 ("chmod 710 .fetchmailrc")!

With the .fetchmailrc from the Example 7-1 above, all email will be forwarded to the local OTRS account, if the command fetchmail -a is executed. Set up a cronjob with this command if you want to fetch the mails regularly.

Filtering/dispatching by OTRS/PostMaster modules (for more complex dispatching)

If you use the bin/otrs.PostMaster.pl or bin/otrs.PostMasterMailbox.pl method, you can insert or modify X-OTRS header entries with the PostMaster filter modules. With the X-OTRS headers, the ticket system can execute some actions on incoming mails, sort them into a specific queue, change the priority or change the customer ID, for example. More information about the X-OTRS headers are available in the section about adding mail accounts from the OTRS Admin page.

There are some default filter modules:

The job name (e.g. $Self->{'PostMaster::PreFilterModule'}->{'JobName'}) needs to be unique!

Kernel::System::PostMaster::Filter::Match is a default module to match on some email header (e.g. From, To, Subject, ...). It can set new email headers (e.g. X-OTRS-Ignore: yes or X-OTRS-Queue: spam) if a filter rule matches. The jobs of the Example 7-2 can be inserted in Kernel/Config.pm

    # Job Name: 1-Match
    # (block/ignore all spam email with From: noreply@)
    $Self->{'PostMaster::PreFilterModule'}->{'1-Match'} = {
        Module => 'Kernel::System::PostMaster::Filter::Match',
        Match => {
            From => 'noreply@',
        },
        Set => {
            'X-OTRS-Ignore' => 'yes',
        },
    };
    # Job Name: 2-Match
    # (sort emails with From: sales@example.com and Subject: **ORDER**
    # into queue 'Order')
    $Self->{'PostMaster::PreFilterModule'}->{'2-Match'} = {
        Module => 'Kernel::System::PostMaster::Filter::Match',
        Match => {
            To => 'sales@example.com',
            Subject => '**ORDER**',
        },
        Set => {
            'X-OTRS-Queue' => 'Order',
        },
    };

Kernel::System::PostMaster::Filter::CMD is a default module to pipe the email into an external command. The output is given to STDOUT and if the result is true, then set new email header (e.g. X-OTRS-Ignore: yes or X-OTRS-Queue: spam). The Example 7-3 can be used in Kernel/Config.pm

    # Job Name: 5-SpamAssassin
    # (SpamAssassin example setup, ignore spam emails)
    $Self->{'PostMaster::PreFilterModule'}->{'5-SpamAssassin'} = {
        Module => 'Kernel::System::PostMaster::Filter::CMD',
        CMD => '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"',
        Set => {
            'X-OTRS-Ignore' => 'yes',
        },
    };

Of course it's also possible to develop your own PostMaster filter modules.