Latest revision as of 15:47, 24 June 2012

There is no link to this page anywhere on the wiki! Nobody will be able to find it, unless she or he knows this page's name. Please add a link to this page in an appropriate location.

[edit] Email hosted by syn₂cat

If you have some email that is hosted by syn2cat, here is how to change the settings. Everything happens on syndi.hackerspace.lu.

[edit] Generalities

As per RFC822/2822/5322, an email address decomposes into local-part@domain. In these instructions replace the strings "localpart" and "DOMAIN" by their actual values for the address or domain you want to configure.

In general, the setup is two-level: an admin can either directly configure a domain or a local-part, or delegate that domain or local-part to a user. If a user gets a domain delegated, (s)he becomes the admin for that domain. All settings are per local-part.

Except as detailed below, at each step ({domain,localpart}×{admin, user}), one can use flat-text files or LDAP for settings. The choice in indifferent, except for subtly different features of the storage system (such as symlinks), and different steps for one address can use a different setting storage technology. However, mixing different storage technologies for the same setting for the same step of the same address will not work.

[edit] flat-text file

Flat text files are in the directory /etc/exim4/virtual/DOMAIN/ for the admin, and in ~/srv/email/DOMAIN/ for users that got a delegation. Each class of setting (e.g. mail routing, spam filtering, greylisting, DNS black/whitelist, ...) is in a different file. They follow a syntax similar to the traditional /etc/aliases, namely a sequence of entries of format

LHS:      RHS

a left-hand-side, a colon, an arbitrary amount of whitespace and then a right-hand-side, then newline. A newline in the RHS can be escaped with a backslash (\). The file is read, matching the current local-part with the LHS; if there is a match, the instructions in the corresponding RHS are followed. First match wins.

The LHS can be

1. a constant string, matching only itself.
2. a perl-compatible regular expression, starting with ^
3. something like "*FOO" (without the surrounding double quotes), matching any local-part that ends with "FOO". In particular, "*" is a catch-all.
4. other things you are unlikely to want to use, but see the info documentation "(spec)Single-key lookup types" for nwildlsearch if you are curious.

[edit] LDAP

LDAP sits at an object of class mailDomain at dc=DOMAIN,dc=hackerspace,dc=lu for admin and at dc=DOMAIN,uid=DELEGATED_USER_UID,ou=People,dc=hackerspace,dc=lu for users that got a delegation. The settings for one local-part are grouped together in a child of that, of class mailAlias at sub-address mailLocalPart=local-part.

The value of the attribute for the setting contains the instructions to be followed for that setting; the syntax of that is always the same as the RHS of the flat-text file.

[edit] Delegations

[edit] flat-text files

To delegate a whole domain, just symlink /etc/exim4/virtual/DOMAIN to ~USER/srv/email/DOMAIN.

To delegate one or several local-parts, use file "delegations". The RHS should be the username you want to delegate to. For example "echo '^sim[0o]n([-+].*)?: sim0n' >> /etc/exim4/virtual/DOMAIN/delegations" to delegate sim0n@DOMAIN, simon@DOMAIN, sim0n-ANYTHING@domain, sim0n+ANYTHING@DOMAIN, etc to user sim0n.

[edit] LDAP

LDAP is not able to delegate whole domains.

To delegate one local-part, create an object of class mailDelegation at sub-address mailLocalPart=local-part, with attribute uid=UID-TO-DELEGATE-TO.

For example: (\ designating that there is NO linebreak)

echo -e 'dn: mailLocalPart=local-part,dc=DOMAIN,dc=hackerspace,dc=lu\nchangetype: add\nobjectClass: mailLocalPart\nobjectclass: \
mailDelegation\nuid: UID\nmailLocalPart: local-part' | ldapmodify -x -D cn=admin,dc=hackerspace,dc=lu -H ldap://localhost

[edit] Mail routing

Mail routing is deciding where some email goes.

[edit] the syndi.hackerspace.lu domain

For mail in the syndi.hackerspace.lu domain, traditional UNIX processing (extended and automated) is done: you have address USERNAME@syndi.hackerspace.lu, you can use .forward, .procmailrc, .maildrop, etc files in your home directory and these files will be used automatically.

The default delivery is to ~/Maildir/, not /var/mail/USERNAME.

The ~/.forward file supports exim extensions, or SIEVE. See the "filter" info documentation on syndi, or /usr/share/doc/exim4/{filter.txt,README.SIEVE}.gz

[edit] virtual domains

For all other domains, the file is "aliases" and the LDAP attribute is "mailAlias". The RHS (attribute value, respectively) is a comma-separated list of destinations, of the form:

• an email address
• a local-part in the syndi.hackerspace.lu domain
• the special value ":fail:STRING" to make that address not exist; if STRING is non-empty, it is the error message given to the sender. STRING can also specify an SMTP error code.
• the special value ":defer:STRING" to try again later; if STRING is non-empty, it is the warning message given to the sender. STRING can also specify an SMTP error code.
• the special value ":blackhole:" to accept the message, but throw it away.

The ":fail:" special value is useful to introduce exceptions to patterns or regular expressions.

For example:

echo 'afarsimon:    sim0n' >> ~/srv/email/DOMAIN/aliases

instructs that the address afarsimon@DOMAIN goes to local user sim0n, assuming you've got local-part sim0n delegated to you by the admin-level config.

echo -e 'dn: mailLocalPart=afarsimon,dc=DOMAIN,uid=YOUR-UID,ou=People,dc=hackerspace,dc=lu\nchangetype: add\nobjectClass: mailLocalPart\nobjectclass: mailAlias\nmailAlias: sim0n\nmailLocalPart: afarsimon' | ldapmodify -x -D uid=YOUR-UID,ou=People,dc=hackerspace,dc=lu -H ldap://localhost

does the same through LDAP.

[edit] sender blacklist

file: sender_blacklist

LDAP attribute: mailSenderBlacklist

format (file): colon-separated list of email addresses, domains, regular expressions (starting with ^), *-patterns (separately for local-part and domain), ... to blacklist. See info documentation "(spec)Address lists" for complete details.

format (LDAP): comma-separated list, otherwise like file. Multiple attributes are automatically merged.

For example:

echo 'afarsimon:    doubleclick.net:spammer@gmail.com:*foo@*.hackerspace.lu' >> ~/srv/email/DOMAIN/aliases

will refuse any mail to afarsimon@DOMAIN that is sent by ANYTHING@doubleclick.net, spammer@gmail.com, ANYTHINGfoo@ANYTHING.hackerspace.lu.

echo -e 'dn: mailLocalPart=afarsimon,dc=DOMAIN,uid=YOUR-UID,ou=People,dc=hackerspace,dc=lu\nchangetype: modify\nadd: mailSenderBlacklist\nmailSenderBlacklist: doubleclick.net\n-\nadd: mailSenderBlacklist\nmailSenderBlacklist: spammer@gmail.com\n-\nadd: mailSenderBlacklist\nmailSenderBlacklist: *foo@*.hackerspace.lu\n-\n' | ldapmodify -x -D uid=YOUR-UID,ou=People,dc=hackerspace,dc=lu -H ldap://localhost

does the same through LDAP.

[edit] Sender whitelist

These senders will be exempted from any sender verification (such as 'does the domain exist', etc).

file: sender_verify_whitelist

LDAP attribute: mailSenderVerifyWhitelist, multiple attributes automatically merged.

format: like sender blacklist

[edit] Sender verify options

How hard does exim try to verify that the sender is legitimate before accepting the mail?

file: sender_verify_options

LDAP attribute: mailSenderVerifyOptions

format:

• "callout" to do a callout (check that the MX for the domain accepts mail to that address)
• "callout=Ns" to timeout after N seconds in the callout
• "callout=defer_ok" to accept the mail if the callout gives a temporary error
• the two can be combined as in "callout=Ns,defer_ok"
• other possibilities: see info documentation "(spec)Additional parameters for callouts"

[edit] DNS greylisting

Greylist (temporarily say "try again later", but after some time accept) all mail coming from an IP that is listed in these DNS-based lists.

file: dns_blacklist_table

LDAP attribute: mailDnsBlacklist; multiples merged

format (file): colon-separated list

format (LDAP): comma-separated list; recommend using only one item per attribute and several attributes.

[edit] DNS blacklisting

Reject all mail coming from an IP that is listed in these DNS-based lists.

file: dns_blacklist_table

LDAP attribute: mailDnsBlacklist; multiples merged

format (file): colon-separated list

format (LDAP): comma-separated list; recommend using only one item per attribute and several attributes.

[edit] MIME defect filtering

If the message has an invalid or fishy MIME structure, reject (deny) it or add a X-syn2cat-MimeErrorLevel header to it (tag).

file: demime_{deny,tag}

LDAP attribute: mailDemime{Deny,Tag}

Default value: :yes:1

format:

•  :no: to not do it
•  :yes:N to do it if the gravity of the MIME defect is above N. N=0 is discouraged. The gravities go from 1 to 3.

[edit] Malware filtering

If the message contains a malware (e.g. a virus, trojan horse, ...) as detected by ClamAV, reject (deny) it or add a X-syn2cat-Malware header to it (tag).

file: malware

LDAP attribute: mailMalware

Default value: :deny:

format:

•  :no: to not do it
•  :deny: to deny
•  :tag: to tag

[edit] Spam filtering

If the message is classified as spam by spamassassin, reject (deny) it or add X-syn2cat-Spam-{Score,Bar,Report} headers to it (tag).

file: spam_{deny,tag}

LDAP attribute: mailSpam{Deny,Tag}

Default value: TODO

format:

•  :no: to not do it
•  :yes:PROFILE:N to do it if the spamassassin score according to profile PROFILE is more that N/10 (N divided by ten; N must be an integer).