Copyright © 2002-2008
EscapeBox Germany
|
|
In case you want to give a user an IMAP/POP email
account you would additionally have to set up that user within the IMAP
subsystem (Cyrus). As user 'root', run the command 'cyradm', with no
arguments. Give it the 'root' user's password when it asks ('root' is
the IMAP administrator). For this example we are going to use the user
name 'bigboss'. On the command line type
cm user.bigboss
sam user.bigboss root all
Never forget the 'user.' prefix! You can add
additional IMAP subfolders:
cm user.bigboss.Received
cm user.bigboss.Sent
cm user.bigboss.Spam
For a list of installed IMAP accounts just type
lm
and to inspect the granted rights for a particular folder you would
type
lam user.bigboss
lam user.bigboss.Sent
and so on. Note that subfolders inherit the rights of their parents.
If you want to prevent users from flooding the
disk by receiving huge emails you can set quotas on individual mailboxes.
The IMAP subsystem has its own quota system that is independent of the
UNIX system. To set a quota of 1 MB, do
sq user.bigboss 1024
Quotas are in kB and are effective for the entire
folder hierarchy beneath a given quota root. The current usage and limit
can be displayed with
lq user.bigboss
In order to remove the quota again, type
sq user.bigboss none
And finally, to get rid of the entire IMAP
mailbox, including subfolders, do
dm user.bigboss
Note that under IMAP you cannot use a dot in your
user name since that character is used as a separator for folder name
components. You can, however, use email aliases (in the mailer daemon)
to map names with dots to user account names without dots.
If you are done leave 'cyradm' with
quit
Although IMAP is a self-contained subsystem,
for authentication purposes, that is, when a user wants to log into
it to get at his mailbox, it uses the system wide password service.
So you do not have to worry about having to change passwords in
multiple places. The 'passwd' command does it all.
In order for the mailer daemon to know that you
want to use your IMAP mailbox from now on you have to put a '.forward'
file into your home directory, with the following contents:
bigboss.INBOX
The mailer daemon automagically knows that it
is an IMAP mailbox if it sees the separating dot. 'INBOX' is just the
synonym of your top IMAP folder. Note that the '.forward' file has to
be owned by the respective user, in this case 'bigboss'. Otherwise
the mailer daemon does not accept this file for security reasons!
Now that you have converted your account to IMAP
mode you could also, for the sake of completeness, install the following
symlink:
ln -s /box/etc/dot.muttrc .muttrc
This automatically sets up 'mutt', the locally
installed email client, in a way that it knows a) about the main domain
name to use in outgoing email, and b) how to access the IMAP daemon.
So you do not have to tinker with that on your own. 'root' and 'bigboss'
use that link as well.
From the remote you can access your email folders
with both the IMAP4 and POP3 protocol, SSL encrypted or not. POP3,
however, allows access only to your main (top) mail folder. We therefore
recommened that you use IMAP4 wherever you can since with its subfolder
support etc. it is superior to POP3.
|
|
|
Instead of redirecting email directly into your IMAP folder by means
of a '.forward' file you can install a '.procmailrc' file for
advanced email filtering and redirection. If the mailer daemon finds
this file it automatically starts to use it. You do not need to do
anything but fill it with useful content (but do not forget to remove
'.forward', since this takes precedence over '.procmailrc'!).
If you like to directly store email in IMAP subfolders you can do it
like this (in this case to eliminate some spam):
:0
* ^Subject: .*xxx
! bigboss.Spam
:0
* ^X-RBL-Warning:
! bigboss.Spam
:0
! bigboss.INBOX
The second paragraph shows how you can make use of Realtime Blackhole
List (RBL) services. By default, two lists provided by DSBL are
configured in each box. Whenever an email comes in from an IP address
that is already registered as an open email relay or a mail server
owned by known spammers (according to the RBL services) a warning
header is added to that email which you can use, as in this example,
to trigger an appropriate action. Instead of putting the message into
a spam folder you could of course also dispose of it immediately by
filing it away in that infinite capacity write-only folder
'/dev/null'. ;-)
Here is another example using the preinstalled
SpamAssassin daemon to separate the chaff from the wheat:
:0 fw
| /usr/local/bin/spamc -p 49146
:0
* ^X-Spam-Status: Yes
! bigboss.Spam
:0
! bigboss.INBOX
The first paragraph filters the email messages through
SpamAssassin (via the client 'spamc'). Note that we give an explicit
port number since in our setup the corresponding 'spamd' listens on one
of the firewalled ports (see "Access control" in chapter "Server protection")
in order to protect it from abuse. The second paragraph then checks
whether an "X-Spam-Status: Yes" header line has been generated by
SpamAssassin, and if so it dumps the message into the "bigboss.Spam" IMAP
folder for later inspection. The 'spamd' daemon is disabled by default.
To enable it just activate its start/stop script '220.spamd.sh'
under '/usr/local/etc/rc.d'.
Tip: SpamAssassin is pretty expensive on both memory
and CPU, and slow because of all the things it has to check. Therefore you
may want to use a multi-step approach. We recommend to first branch off
messages from sufficiently trusted sources, namely mailing lists you are
on. This can be achieved by filtering on headers that are typical for the
respective source.
Secondly, eliminate those messages the mailer daemon already (in an
inexpensive way) detected as being blacklisted (header "X-RBL-Warning").
And finally, let SpamAssassin deal with the few remaining messages
(pipe through 'spamc' and filter on header "X-Spam-Status"). This makes
for the most bang for the buck.
In order for spam redirection to work the way
outlined above, there are two prerequisites: You
need an IMAP subfolder 'Spam' (see 'cyradm' example above), and you
need a '.forward.Spam' file with this contents:
bigboss.Spam
That is, it points to itself, but the mailer daemon is intelligent
enough to prevent a loop. We use it as kind of a gate keeper. For
security reasons you can post mail messages directly only to
subfolders for which such a forward file exists.
While we are at it, if you install a file '.forward.Sent' with the
contents:
bigboss.Sent
you can BCC copies of what you send by email and news directly to an
IMAP 'Sent' subfolder. So you have a central sent folder for any number
of email clients, wherever you are.
In the above example we used the widespread procmail filter program.
There are similar filter capabilities directly built into the mailer
daemon (Exim). Their advantage is that they use less CPU resources
since there is no external program call for each mail like with procmail.
You can find the manual among the documentation in the "Server Box
Information Area".
|
|
|
While email is stored in the Cyrus IMAP subsystem and accessed by the
user with the IMAP4 or POP3 protocols, the actual transport of email
between Internet servers is done by the mailer daemon (Exim), even
encrypted if both sides are capable of SSL.
For incoming email it makes sure that messages get forwarded to the proper
destination (email folder, procmail filter, mail to news gateway etc.).
It does that with the help of directions it finds in its alias
file ('/etc/mail/aliases') and the various '.forward' files a user can
have.
For outgoing email the mailer daemon acts as a proxy. You can configure
the mail client on your computer at work or at home to just dump the
message into the mailer daemon in your box, which will then take care
that it actually gets delivered. In order to do that your mail client
has to be able to authenticate itself (with your username and password)
when it wants to send email (SMTP-Auth). Without that authentication step
spammers would be able to abuse your box to swamp the net with their crap.
Please use SSL here as well if you can since otherwise your password
gets transmitted over the Internet unprotected.
Unfortunately, though, more and more Internet access
providers block SMTP connections (port 25) coming from endusers, in order
to prevent hijacked PCs from distributing spam. In this situation you
may want to enable the start/stop script '260.exim-2.sh' under
'/usr/local/etc/rc.d', which starts a second Exim daemon that listens
on port 8025. This instance has the same advanced features as the
main Exim daemon, like 'libwrap' support, SSL etc., and uses the
same resources and config files. All you would then have to do is
re-configure the affected mail clients to connect to the mail server
on port 8025 instead of the default port 25.
|
|
|
Our server boxes can deal with multiple email domains
as well as virtual user accounts. Setting this up is easy. First, you
need user accounts to authenticate against. These can be normal or virtual
accounts (the latter without login capability). For separate name
spaces we suggest the following naming convention:
john_6381
where 'john' is the user's individual name and '6381' would be a unique
number assigned to each individual domain name,
in this example 'sundry.org'.
The most intuitive way to name
user accounts would have been 'john_sundry.org'. However, apart from the
fact that FreeBSD supports only user names of up to 16 characters, email
clients may get into trouble with long user names as well. So, for the
sake of compatibility, a conservative approach is called for, and since
each user has to deal with this name only once (when configuring his email
client) the esthetics of these naming conventions are of little relevance to
everyday use.
Generating user accounts can be partially automated.
Here is an example for setting up a virtual account (no home directory):
echo 'plaintextpassword' |
pw useradd -n john_6381 -g customer -c 'John Doe' \
-d /nonexistent -s /sbin/nologin -h 0
This sets up an account 'john_6381', group 'customer'
(which is assumed to exist already), real name 'John Doe' and password
'plaintextpassword'. You may want to run 'apg' to get a number of
(pronounceable) password suggestions. Note that you can use these
accounts for web authentication purposes as well (automatically via
'mod_auth_pam').
Now you need the actual IMAP/POP email folders.
As user 'root', run 'cyradm' and authenticate with the 'root' password.
Generate the email folder with
cm user.john_6381
sam user.john_6381 root all
You may want to add subfolders at this point.
Alternatively, the user can do this himself from his IMAP client.
Or if POP is used subfolders are of no relevance here, anyway.
Finally, add aliases to '/etc/mail/domainaliases'
(does not exist by default), for instance
john@sundry.org: john_6381.INBOX@localhost
johndoe@sundry.org: john_6381.INBOX@localhost
john.doe@sundry.org: john_6381.INBOX@localhost
postmaster@sundry.org: postmaster@localhost
*@sundry.org: catchall_6381.INBOX@localhost
'postmaster' would be the central domain-independent postmaster account
(defined in '/etc/mail/aliases'), while 'catchall_6381' is just another
IMAP/POP account that gets all email not dealt with by other domain
aliases. '@localhost' means that the target address points to the
domain-independent name space, that is, aliases in '/etc/mail/aliases',
local mailing lists, IMAP/POP accounts etc.
In case you would like to filter out spam for
these users you would have to set up individual home directories
for them, like you would do for "normal" users, but provided you keep
giving them a shell of '/sbin/nologin' they still cannot log into the
system by shell or FTP. Here is an example:
echo 'plaintextpassword' |
pw useradd -n john_6381 -g customer -c 'John Doe' \
-s /sbin/nologin -h 0 -m
Fill the resulting directory '/home/john_6381'
with a set of '.procmailrc' and '.forward.*' files (watch the file
permissions!), as described in chapter "Email filters", and strip the
'.INBOX' suffix from the respective domain aliases above to allow for
full email processing.
Note: Always keep '/box/cfg/domains' in sync with
the domain names you define in '/etc/mail/domainaliases', or else the
email system and other services will not be aware that these domains
are to be considered local!
|
|
|
Virtual email accounts differ from normal UNIX
user accounts in that users cannot log into them by shell or FTP, but
they still can have home directories. This way you can set up spam
filtering for individual email users in the same way as for normal
users.
There are two utilities that aid you in dealing
with virtual email accounts: 'add_vuser' and 'del_vuser'. Their syntax
is as follows:
add_vuser [<user> <group> <password> [<domainalias>]]
del_vuser [<user>]
'add_vuser' sets up the account in the UNIX '/etc/passwd' system, the
IMAP email subsystem, in '/etc/mail/domainaliases' (in case of virtual
email domains), and also creates a stub home directory, all in one go.
If '<group>' does not exist it will be created. Similarly,
'del_vuser' removes the account again, in all subsystems involved,
including aliases in '/etc/mail/aliases' and '/etc/mail/domainaliases'
that point to this account. Both commands require you to enter the 'root'
password once, for the IMAP subsystem. Note that you can use these
accounts for web authentication purposes as well (automatically via
'mod_auth_pam').
The command line arguments above are marked as
optional because you can omit them and instead feed an argument
list to stdin, in the same format as on the command line, one
line per user if more than one account is to be added/deleted (batch
processing). Note that sanity checking for duplicate/missing accounts
takes place for the whole batch in advance, before changing anything.
|
|
|
There is also mailing list functionality built into the mailer daemon.
While specialized mailing list software is certainly more capable,
the more simple approach provided directly by the mailer daemon
is probably sufficient in most cases.
All you need to do is this: Under '/usr/local/etc/exim/mlists' create a
subdirectory with the name of the domain the mailing list should
live under, probably your box's main domain name.
cd /usr/local/etc/exim/mlists
mkdir mydomain.tld
Within this directory create a subdirectory with the name of your
mailing list:
cd mydomain.tld
mkdir mylist
Now, in this directory create a file 'sub' (subscribers) and fill
it with a list of fully qualified email addresses ('user@some.domain.tld'),
one address per line. Email to the mailing list will be forwarded
to users in this file.
Next, create a file 'adm' (administrator) and put the email address
of the individual who runs this list into it. Error mails (bounces
etc.) will be forwarded to this user instead of all list subscribers.
If you would like an archive of the mailing list, create a file 'arc'
(archive) and put the path of that archive file into it, for instance
'/var/spool/mlists/mydomain.tld/mylist'. The directory '/var/spool/mlists'
exists by default, so all you have to do is created the subdirectory
for the domain the mailing list lives under:
cd /var/spool/mlists
mkdir mydomain.tld
chown mailnull:mail mydomain.tld
Watch the file permissions. Everything under '/var/spool/mlists'
has to belong to and be writable by the 'mailnull' user. With the first
message to the list the mailer daemon will create the file 'mylist'
and append subsequent messages to it, as you would expect of an
archive.
At this point you have a list that everybody who knows the
address 'mylist@mydomain.tld' can send mail to. This is called an
open list. If you would rather like a closed list, that is, a
list into which only a selected group of people can inject mail,
you need to create the additional file 'snd' under
'/usr/local/etc/exim/mlists/mydomain.tld/mylist' and fill it
with fully qualified email addresses, in the same format as
the 'sub' file. If the group that can send email to the list
happens to be identical with the subscriber list you do not need
an extra 'snd' file. Just install a symlink pointing to 'sub':
ln -s sub snd
The files for an open mailing list 'mylist@mydomain.tld' under
'/usr/local/etc/exim/mlists/mydomain.tld/mylist' would now look like this:
2 -rw-r--r-- 1 root wheel 19 May 29 22:03 adm
2 -rw-r--r-- 1 root wheel 33 May 30 10:16 arc
2 -rw-r--r-- 1 root wheel 62 Jun 25 20:34 sub
|
|
|
There is is news (usenet) system installed in each server box. You
can use it, for instance, to provide announcement and discussion
groups to your users, be it in corporate or private context (club
members, buddies etc.). All the user needs at his end is a news
client software capable of access authentication.
An especially intriguing application is, however, its use in
combination with the mail-to-news gateway we included. If you are
on high volume mailing lists you will know what a pain it is having
to read them in that single email folder you have had so far.
Now, with the help of procmail filters you can funnel mailing
list email into respective local newsgroups, in order to deal with
vast amounts of traffic efficiently by reading the lists with a
newsreader, with proper threading, auto-expire and all. Here is how
you would do that in '.procmailrc':
:0 ir
* ^Sender: owner-freebsd-security-notifications@FreeBSD\.ORG
| /usr/local/news/bin/mail2news/mail2news \
mlists.freebsd.security-notifications
In this case FreeBSD security notifications go into newsgroup
'mlists.freebsd.security-notifications'. If you also would like to
eliminate the distracting tags some mailing lists put into the subject
line, add a second argument to the 'mail2news' call (it is internally
passed to 'sed'):
:0 ir
* ^List-Id: .*<newsticker\.listserv\.heise\.de>
| /usr/local/news/bin/mail2news/mail2news \
mlists.heise-ticker "/^Subject:/s/: \[Newsticker\]/:/"
This would get rid of tag '[Newsticker]'.
Besides setting up '.procmailrc' for that purpose, you of course need
to create the local newsgroups with
/usr/local/news/bin/ctlinnd \
newgroup mlists.freebsd.security-notifications y
/usr/local/news/bin/ctlinnd \
newgroup mlists.heise-ticker y
You also may want to fine-tune the expiration of these newsgroups. Do
that in '/usr/local/news/etc/expire.ctl'.
That's it. Now you can connect to the box's news service (preferably with
SSL), authenticate and subscribe the mailing list newsgroups. Note that
this gateway is unidirectional, so posting messages to the list is
still done by email.
The most complicated issue in this setup is actually finding out how
to detect the respective mailing lists properly. Unfortunately there
is no standard for this, so you will have to look at the mail headers
of each individual mailing list to pick a line that appears to identify
the list reliably and use that in your procmail filter rule.
Finally, you can combine spam filtering with the
mail-to-news gateway. Just set up a newsgroup for the spam and
redirect the messages to it via the mail-to-news gateway, instead of into
a separate email folder. This way you get a rolling spam buffer with
auto-expire (14 days by default) that you need to deal with only in case
you suspect a legitimate email has been misfiled there.
|
|
|
|
|
