Courier mail server linux

Почтовый сервер — Courier Mail Server

Почтовый сервер на основе открытых протоколов ESMTP, IMAP, POP3, LDAP, SSL и HTTP.

Courier Mail Server (The Courier Mail Server) может функционировать как почтовый релей (mail relay) между внутренней локальной сетью LAN сетью интернет или выполнять окончательную доставку писем в почтовые ящики. Этот почтовый сервер наиболее известен за свою серверную компоненту IMAP (сервер электронной почты).

Courier Mail Server использует Maildir как свой родной формат хранения данных. Файлы конфигурации имеют текстовый формат и могут включать в себя скрипты Perl, может обеспечивать почтовые услуги для учетных записей операционных систем. Courier Mail Server может также обеспечить почтовые услуги для виртуальных почтовых аккаунтов, управляемых любой службой каталогов LDAP, Berkeley DB, MySQL или базой аутентификации PostgreSQL.

Компоненты Courier Mail Server, такие, как система фильтрации maildrop, серверы webmail и IMAP, могут быть установлены также как независимые пакеты, которые можно использовать с другими почтовыми серверами. Courier-IMAP популярен в комбинации с серверами Qmail, Exim и Postfix, которые конфигурируются, чтобы использовать формат хранения электронной почты Maildir.

Несмотря на наличие в комплекте таких составляющих как SMTP сервер, pop3d и системы ведения списков рассылки. Courier MTA — это прежде всего 3 составляющих: базирующийся на Maildir IMAP сервер, система фильтрации почты maildrop и удобная система работы с почтой (включая проверку орфографии, адресную книгу через LDAP и индивидуальную настройку фильтров) посредством web-интерфейса (webmail).

Исходный код Courier Mail Server компилируется на большинстве POSIX-подобных операционных систем, основанных на ядрах Linux и BSD.

Источник

Courier Mail Server

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Courier MTA is a mail transfer agent and POP3/IMAP4 server with Courier. This article builds upon Mail server.

The advantages of Courier-MTA are:

• Authentication for MTA and POP3/IMAP happens against one data source
• This data source can be a MySQL, PgSQL or LDAP, but also can be simpler like PAM or a compiled plaintextfile (BerkeleyDB)
• Easy support of virtual users
• SMTP-auth out of the box
• Comes with webmail
• Web based administration possible
• Also has a separate mail delivery agent (MDA), if it is needed

Contents

Preamble

The following text describes a setup for two local domains on one physical machine, which is not so uncommon for single users or small companies. We authenticate against a BerkeleyDB-based «.dat» file which is created from a text or multiple textfiles automatically by tools that come with courier. This method is described in the Courier documentation as authuserdb, so do not get confused about names. The authentication against other providers happens in an adequate way and is covered in courier-authlibs documentation. There are differences in the handling of SASL methods (such as PLAIN or CRAM-MD5) depending on which authentication backend (authuserd, authpam, authmysql . ) you like to use. Just do not expect that this setup can be painlessly converted from the described authuserdb to authmysql.

Installation

Any other mail transfer agents (like Cyrus) or SMTP servers (Sendmail, Postfix, etc.) must be uninstalled for this, so answer ‘yes’ when prompted to do so.

Authuserdb authentication

Let Courier know that we want to authenticate against authuserdb.

In the file /etc/authlib/authdaemonrc find authmodulelist=. then remove all listed modules except for authuserdb:

Creating the vmail user

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

We want to deliver our mail primarily to virtual users, so we can easily create e-mail accounts without creating real users. Granny may want to read her e-mail but she does not need ssh access to that box, does she? To make that possible we need one «physical» user, that owns all of our mails physically on the drive. Note, that this is not the courier user which is primarily there to make sure that the actual server process does not run as root. Many people save this stuff in /var since it is primarily thought for these things. You can create the users «home» just anywhere you want! The decision will be influenced by the partition layout of your drive(s).

Add a user «vmail», who is the lord of all of the mail files:

Creating the email accounts

There is a place where the virtual users and their attributes will be stored. This can be either a plain textfile or a directory where several textfiles are contained. See courier-authlib’s documentation for details. The directory-based approach makes maintenance a bit easier since we can separate the users of domains and subdomains, so we will go with this approach. The name of the directory is not negotiable.

The attributes of the «vmail»-system user need to be stored here, too, since we allowed only authuserdb in /etc/authlib/authdaemonrc . Fortunately, courier comes with a handy script that converts all local users into a file in courier-syntax. This file can be named freely, we call it «system». Later we also create a file for «domain1» and «domain2». Got the idea?

Keep only the «vmail» user (this means that no local user can receive emails!):

Now we create the virtual users in the authentication database. The actual Maildir folders have to be created manually later. This creates a user «user1@domain1» and a «user2@domain2». For details about these commands check the man pages for the command itself and the man pages that are linked to.

Let us set a password for the user (used for PLAIN and LOGIN and APOP):

The following is used for CRAM-MD5 and friends (SASL-methods). Also note that this construct pipes the the password directly into the command and thus can be read as cleartext, but can be handy for shell scripts that create new users:

• user2 (repeat for user2@domain2):

Setting up Maildirs

We need to create the virtual users «Maildir» as a physical place on the hard-drive in the «vmail»-system user home directory. Note that the «vmail» user needs write rights and also will own the files. It is easiest to create that stuff as the «vmail» user:

Leave «vmail» account and become root:

Make sure you become root again by leaving the «vmail» account by typing exit as shown above.

Creating the user database

Now it is time to create the BerkeleyDB from the plain text files. It is important that the files in /etc/authlib/userdb are visible for root only. If they have any world or group rights, courier will not allow the creation of the db-files from the information.

Now we can check if the authentication works. Courier comes with a little tool that checks if users can be authenticated. Before using this tool, we must make sure the authentication daemon is running by enabling authdaemond.service . Then:

If you encounter any errors while testing the authentication, please consult these instructions, which detail how to use debugging features to pinpoint the problem.

Configuring courier

Now we are now done with authentication stuff. It gave us a flexible layout which can be easily extended. Time to move on to courier’s configuration itself. First, we will try to give some aliases for the server. The aliases follow the userdb’s scheme very closely. Unlike in other servers, there is no need to handle with all aliases in just one file. Again, you can create several plain text files in one folder, where you can handle the aliases by domains or even finer structured if you like. The folder’s location is again not negotiable, you must use /etc/courier/aliases . There is already a «system» file which deals with root, postmaster and the usual suspects. Just add a «user1@domain1» behind the existing «postmaster: » to have all system relevant mails delivered to «user1@domain1». We just assume that this user is your primary account.

Repeat that for every domain and user, in our test case for user2@domain2. It might help to create another scheme here like naming your files domain1.user1 which makes administration easier and more transparent. This will also help on automated, script-based administration.

Finally, these aliases must be exported to the BerkeleyDB. Again, Courier comes with a little utility for that task, it is called makealiases :

Just check if everything is fine:

Setting localdomain and hosteddomains

Now we need to tell courier the who is who on this box — who we serve e-mail for and who we do not. Courier separates this into these levels:

• locals: This is localhost for sure and on dedicated servers you are mostly part of a domain like server234.serverfarm.tld
• hosteddomains: For your hosted domains and subdomains like my-cool-domain.ca, project1.my-cool-domain.ca

For example, lets say you have a server at blahfarm.com. Usually they make your server a host on their domain. This is likely something like server234.blahfarm.com . Now, you want your server available from the web by a more meaningful and even cooler name, so you buy (or rent) a domain name like my-cool-domain.ca . In this case the setup looks like this:

locals: localhost server237.blahfarm.com hosteddomains: my-cool-domain.ca project1.my-cool-domain.ca smtp.my-cool-domain.ca

To learn the difference between these specifications, read the manpage for makehosteddomains . You will figure that the following suits our approach:

Again, these values must be converted into a BerkeleyDB — use the courier command:

Before we go on, one more thing needs to be written — the domain(s) we accept mail for. In the directory /etc/courier/esmtpacceptmailfor.dir/ we will create a file named domain1 and type domain1 into it:

Repeat for domain2:

Finally, convert into a BerkeleyDB:

. and you are done here.

Testing your setup

Now the server is ready. Let us run several tests on the SMTP server and see if it is working nicely at least for sending and receiving mails.

Let us test some more stuff, which can be useful.

Send an ordinary mail (as root or ordinary user):

Send a mail to an alias:

Send a mail to an external email address:

Configuring IMAP and POP3

So far, our operations have been focused on the box which runs the server itself. Now we need to setup some interaction related configuration. Since security is important we will setup some nice authentication modes, which does not send cleartext passwords. Courier supports CRAM-MD5 among others. You will have to make sure that your clients support that too. So far I tested sylpheed-claws > 1.0.4, esmtp and Thunderbird with these settings.

Now it comes in, that we will have to configure the several server daemons. Courier is already running (from the perftest above) but it does not provide services to the network. So we have to configure esmtpd, pop3d and imapd with their respective configuration files in /etc/courier/ .

Since we like to use SMTPAuth instead if a IP/Domain based SMTP authentication we need to activate the AUTHREQUIRED option in esmtpd. Also we activate the CRAM-MD5 challenge method for authorization. NOTE: this setup definitely keeps Outlook losers out. For these buggy and old fashioned clients you will need to use way less restrictive settings!

The imapd setting is a bit different. In /etc/courier/imapd there is a long line starting with IMAP_CAPABILITY. Just add a «AUTH=CRAM-MD5» at the end of the arguments and you should be done:

Remarks

Because of our very small test case with just two boxes and no domain control we have to take a look at Courier’s intrinsics and work around a little issue. Courier is nitpicking about RFC compliance, which does mean you have to make sure that you understand how to configure your e-mail clients for testing. This will fail in our testing:

Why? Because you send from a non-valid domain name. I assume here, that we use our «domain1» and «domain2» testpark. Now, when you create an account in Sylpheed which looks like this: Name: user numberone Address: user1@domain1 Sylpheed consequently sends the mail as «user numberone «. This is wrong, since it violates the RFC. You get a Error: 517 — Syntax Error. For the testing you can simply fool Courier-MTA by setting the domain in sylpheed’s dialog to: Address: user1@domain1.xx

Something similar (you just get Error 513 — Syntax Error) happens in this case:

Источник

Courier-0.47

Введение в Courier

Пакет Courier содержит Mail Transport Agent ( MTA ). Он полезен для отправки почты другим пользователям на вашей машине. Так же он может быть настроен в качестве центрального сервера почты вашего домена или в качестве агента перенаправления почты. Пакет Courier так же включает web-основанный интерфейс почты, IMAP , IMAP — SSL , POP 3 и POP 3- SSL .

Информация о пакете

Контрольная сумма: 639bb3b236914e3b86f287ce3f55264e

Требуемое дисковое пространство: 102 MB

Расчетное время сборки: 2.62 SBU

Зависимости Courier

Требуемые

Опционально

Установка Courier

Замечание

Тарбол Courier должен быть распакован с правами обычного пользователя, иначе скрипт configure выпадет с ошибкой.

Перед началом сборки программы вам надо создать пользователя и группу courier, которые должны присутствовать в системе перед запуском скрипта install. Как пользователь root, добавим пользователя и группу courier при помощи следующих команд:

Скрипт install так же ожидает наличия пользователя bin. Если у вас уже есть пользователь с именем bin, то этот шаг может быть пропущен.

Courierfilter требует директорию /var/run/courier для сохранения всех pid и lock-файлов для Courier . /var/lock/subsys так же должен присутствовать для основного lock-файла Courier . Выполним следующие команды для создания этих директорий:

Соберем Courier под непривилегированным пользователем при помощи следующих команд:

А теперь опять станем пользователем root и установим Courier при помощи следующих команд:

Описание команд

--libexecdir=/usr/lib/courier: Описывает директорию, которая содержит программы и библиотеки, которые не могут быть непосредственно запущены из командной строки.

--datadir=/usr/share/courier: Описывает директорию, в которую будут установлены различные скрипты оболочки, Perl скрипты и файлы данных.

--localstatedir=/var/spool/courier: Описывает директорию, которая будет содержать очередь почты и другие временные данные.

--with-piddir=/var/run/courier: Описывает директорию, в которой сохраняются PID файлы Courier когда Courier активен.

—with-paranoid-smtpext: Быть параноиком при переговорах Courier-specific ESMTP расширений с удаленными серверами. Почтовый сервер Courier описывает и реализует некоторые экспериментальные ESMTP расширения: XVERP и XEXDATA. Проблемы могут быть следствием событий, когда кто-то другой использует то же самое имя для реализации другого расширения. Если эта опция описана, то ESMTP сервер Courier а так же будет объявлять фиктивную возможность ESMTP , называемую XCOURIEREXTENSIONS, и не будет узнавать любые Courier-специфичные расширения пока удаленный почтовый сервер так же объявляет эту фиктивную ESMTP возможность.

—disable-autorenamesent: Не переименовывать папку Sent каждый месяц. Так же эта опция может быть контролирована переменной окружения SQWEBMAIL_AUTORENAMESENT.

—enable-workarounds-for-imap-client-bugs: Есть несколько подтвержденных ошибок в некоторых клиентах IMAP , которые не правильно реализуют протокол IMAP 4rev1. Эта опция включает некоторые обходы для этих ошибочных IMAP клиентов. ЗАМЕЧАНИЕ: make check при использовании этой опции будет выпадать. Сначала вы должны использовать configure без этой опции и, если все послеконфигурационные тесты проходят, перезапустить configure с этой опцией и пересобрать.

--with-db=gdbm: Courier так же требует библиотеку базы данных GDBM или DB . GDBM используется если присутствуют обе. Эта опция принудительно выбирает GDBM , так как в данный момент courier не работает при использовании DB .

--with-ispell=/usr/bin/aspell: Сервер интернет почты Courier может использовать проверку орфографии если configure находит ispell или если вы точно установите положение aspell .

Источник