Email (deprecated)

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.

---

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.

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.

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.

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.

Delegations

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.

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

Mail routing

Mail routing is deciding where some email goes.

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

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.

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.

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

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"

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.

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.

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.

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

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).