Email (deprecated)

From syn2cat - HackerSpace.lu
(Difference between revisions)
Jump to: navigation, search
(Sender verify options)
(DNS black/greylists)
Line 120: Line 120:
 
* the two can be combined as in "callout=Ns,defer_ok"
 
* the two can be combined as in "callout=Ns,defer_ok"
 
* other possibilities: see info documentation "(spec)Additional parameters for callouts"
 
* 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.

Revision as of 17:06, 15 March 2011

Contents

Email hosted by syn2cat

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:

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.

Personal tools
Namespaces

Variants
Actions
Navigation
syn2cat
Hackerspace
Activities
Initiatives
Community
Tools
Tools