NAME

aliases_check - check recipients against aliases file


DESCRIPTION

This plugin looks up recipients (argument to the RCPT TO command) in an alias file. Recipients which are not found are immediately rejected. For each found recipient, the recursive expansion of the alias and the per-recipient options (if any) are noted. Typically, the aliases_rewrite plugin is then used to replace the recipient list. The options can be used by other modules to implement different behaviour for different recipients.

An alias can expand to one or more addresses, a detail string (everything after '+' in the local part) is preserved in the expansion.

Duplicates are eliminated.

Unlike the sendmail aliases file, the aliases are complete email addresses, not just the local part.


CONFIGURATION

The aliases file is a simple text file, with one alias-pattern/expansion pair per line, separated by a colon.

The alias pattern consists of a list of local parts, an @ sign and a list of domains, optionally followed by a parenthesized list of of options.

The expansion consists of a list of email-addresses.

Lists are comma-separated, whitespace is insignificant.

For example, consider the alias file:

    hjp,peter.holzer@wsr.ac.at,wifo.at: hjp@asherah.wsr.ac.at (denysoft_greylist, spamassassin_reject_threshold=10)
    postmaster@,wsr.ac.at,wifo.at: sysadm@wsr.ac.at
    sysadm@wsr.ac.at: hjp@wsr.ac.at,gina@wsr.ac.at

The addresses <postmaster>, <postmaster@wsr.ac.at> and <postmaster@wifo.ac.at> would all be expanded to <sysadm@wsr.ac.at>, which in turn would be expanded to two adresses (, <gina@wsr.ac.at>), of which the first would again be expanded to <hjp@asherah.wsr.ac.at>.

So if you send mail to <postmaster+test@wsr.ac.at>, it will be delivered to <hjp+test@asherah.wsr.ac.at> and <gina+test@wsr.ac.at>.

The options are stored in the transaction notes with key recipient_options and can be accessed by other plugins. They are not recursively expanded, however, so in the above example, the greylisting plugin would only be active for the hjp and peter.holzer addresses, not for postmaster and sysadm.

The ability to specify patterns doesn't add any functionality: The first line in the example above is exactly equivalent to:

    hjp@wsr.ac.at: hjp@asherah.wsr.ac.at (denysoft_greylist, spamassassin_reject_threshold=10)
    peter.holzer@wsr.ac.at: hjp@asherah.wsr.ac.at (denysoft_greylist, spamassassin_reject_threshold=10)
    hjp@wifo.at: hjp@asherah.wsr.ac.at (denysoft_greylist, spamassassin_reject_threshold=10)
    peter.holzer@wifo.at: hjp@asherah.wsr.ac.at (denysoft_greylist, spamassassin_reject_threshold=10)

But it should help to keep the expansions consistent.

The order of lines is not significant. If two lines for the same alias exist, it is undefined which one is used. (In the current implementation, later entries override earlier ones but this should not be relied upon).


HOOKS

rcpt

check_rcpt


TRANSACTION NOTES

This plugin fills in two transaction notes with information about the recipients:

expanded_recipients

A reference to a hash of arrays. The keys of the hash are the recipients as passed in the RCPT commands and as stored in $transaction->recipients. Each value is a list of addresses this recipient should be replaced with. All addresses are strings, not Qpsmtpd::Address objects, and they are full RFC-2821-style addresses, except that delimiting angle brackets are omitted.

So the aliases file from the example above will result in the followin hash:

    {
        'hjp@wsr.ac.at'          => [ 'hjp@asherah.wsr.ac.at' },
        'peter.holzer@wsr.ac.at' => [ 'hjp@asherah.wsr.ac.at' },
        ...
        'postmaster@wsr.ac.at'   => [
                                      'hjp@asherah.wsr.ac.at',
                                      'gina@wsr.ac.at'
                                    ],
        ...
    }

Typically a plugin hooking into data_post or queue (e.g., aliases_rewrite) will then replace all recipients with the addresses in this note before queuing the message.

recipient_options

A reference to a hash of hashes. The keys are the recipients (same as in expanded_recipients - i.e., before expansion), the values are hashes of options. This plugin produces only simple key/value pairs, but theoretically the options couls be arbitrarily complex data structures.

The aliases file from the example results in the following recipient_options note:

    {
        'hjp@wsr.ac.at' => {
                               denysoft_greylist => 1,
                               spamassassin_reject_threshold => 10
                           },
        'peter.holzer@wsr.ac.at' => {
                               denysoft_greylist => 1,
                               spamassassin_reject_threshold => 10
                           },
        ...
    }


METHODS

rcpt: check_rcpt

The check_rcpt method plugs into the rcpt hook. It looks up the recipient's email address in the aliases file, expands it, and stores the result and per-address options (if any) in transaction notes.

If the address is not found and $connection->relay_client is not set, the request is DENYd, otherwise the request is DECLINED. This plugin should be run before any other plugin which makes use of recipient_options. The last plugin to run must then return OK for all recipients it doesn't DENY. (there is a rcpt_ok plugin which simply accepts all recipients which haven't yet been denied).


BUGS

None known (yet).


TODO

Parsing a text file is fast enough for a few thousand aliases. For larger user bases the text file should be replaced by a database with proper indexes (*DBM, relational, LDAP, whatever).


COPYRIGHT AND LICENSE

Copyright (c) 2003-2006 Peter J. Holzer

This plugin is licensed under the same terms as the qpsmtpd package itself. Please see the LICENSE file included with qpsmtpd for details.