Версия для печати

Архив документации на OpenNet.ru / Раздел "Настройка почты (sendmail, postfix, qmail)" (Многостраничная версия)

Установка и настройка Cyrus IMAP Server

Internet Message Access Protocol (IMAP) является стандартным протоколом Internet для доступа к сообщениям (почта, новости и т. д.). IMAP хранит сообщения и обеспечивет к ним доступ.

Файл  doc/questions.html содержит список вопросов которых анм не задают, но на которые мы хотели бы ответить; doc/faq.html содержит некоторые ответы, над которыми нам пришлось задуматься.

Пожалуйста, обращайтесь к   Sending Feedback если вы хотите узнать о багах, особенностях или патчах.

Для уточнения конкретных изменений смотрите файл  doc/changes в дистрибутиве.
Перевод: Domas I Andrey
Оригинал: cyrus.org.ru

Содержание

Другие материалы

Вот некоторое ПО, которое может работать вместе с Cyrus'ом. Этот софт либо поддерживается либо не поддерживается CMU, это Вы можете уточнить у распространителей(?).


last modified: $Date: 2002/11/14 16:23:04 $ 
Назад
Changes to the Cyrus IMAP Server

Changes to the Cyrus IMAP Server since 2.1.15

Changes to the Cyrus IMAP Server since 2.1.14

Changes to the Cyrus IMAP Server since 2.1.13

Changes to the Cyrus IMAP Server since 2.1.12

Changes to the Cyrus IMAP Server since 2.1.11

Changes to the Cyrus IMAP Server since 2.1.10

Changes to the Cyrus IMAP Server since 2.1.9

Changes to the Cyrus IMAP Server since 2.1.8

Changes to the Cyrus IMAP Server since 2.1.7

Changes to the Cyrus IMAP Server since 2.1.6

Changes to the Cyrus IMAP Server since 2.1.5

Changes to the Cyrus IMAP Server since 2.1.4

Changes to the Cyrus IMAP Server since 2.1.3

Changes to the Cyrus IMAP Server since 2.1.2

Changes to the Cyrus IMAP Server since 2.1.1

Changes to the Cyrus IMAP Server since 2.1.0

Changes to the Cyrus IMAP Server since 2.0.16

Changes to the Cyrus IMAP Server since 2.0.15

Changes to the Cyrus IMAP Server since 2.0.14

Changes to the Cyrus IMAP Server since 2.0.13

Changes to the Cyrus IMAP Server since 2.0.12

Changes to the Cyrus IMAP Server since 2.0.11

Changes to the Cyrus IMAP Server since 2.0.9

Changes to the Cyrus IMAP Server since 2.0.8

Changes to the Cyrus IMAP Server since 2.0.7

Changes to the Cyrus IMAP Server since 2.0.6

Changes to the Cyrus IMAP Server since 2.0.5

Changes to the Cyrus IMAP Server SINCE 2.0.4

Changes to the Cyrus IMAP Server SINCE 2.0.3

Changes to the Cyrus IMAP Server in 2.0

Changes to the Cyrus IMAP Server Since Version 1.6.20

Changes to the Cyrus IMAP Server Since Version 1.6.19

Changes to the Cyrus IMAP Server Since Version 1.6.16

Changes to the Cyrus IMAP Server Since Version 1.6.13

Changes to the Cyrus IMAP Server Since Version 1.6.10

Changes to the Cyrus IMAP Server Since Version 1.6.1-BETA

Changes to the Cyrus IMAP Server Since Version 1.6.0-BETA

Changes to the Cyrus IMAP Server Since Version 1.5.24

Changes to the Cyrus IMAP Server Since Version 1.5.19

Changes to the Cyrus IMAP Server Since Version 1.5.14

Changes to the Cyrus IMAP Server Since Version 1.5.11

Changes to the Cyrus IMAP Server Since Version 1.5.10

Changes to the Cyrus IMAP Server Since Version 1.5.2

Changes to the Cyrus IMAP Server Since Version 1.5

Changes to the Cyrus IMAP Server Since Version 1.4

Changes to the Cyrus IMAP Server Since Version 1.3

Changes to the Cyrus IMAP Server Since Version 1.2

Changes to the Cyrus IMAP Server Since Version 1.1-Beta

Changes to the Cyrus IMAP Server Since Version 1.0-Beta


last modified: $Date: 2003/11/19 16:44:29 $
Return to the Cyrus IMAP Server Home Page

Cyrus IMAP Server: Alternate Namespace

This document describes the alternatives to the standard mailbox presentation method. These alternatives may be used together or independently.

The namespace options do NOT change the rules governing the behavior of mailboxes (as described in overview.html) or how mailboxes are stored on the filesystem. The mailboxes are ALWAYS stored using the netnews convention and internal namespace. When configured to use one (or both) of the options below, the server simply translates mailbox names between the internal names and the external names when used by the client in the IMAP protocol and in Sieve scripts.

This design allows the namespace to be changed at runtime (even on a running server) without having to reconfigure the server. This also means that one mailstore can support multiple namespaces if configured correctly.

NOTE: If you are upgrading an existing server which uses timsieved to manage Sieve scripts and choose to enable one of the namespace options, you should run the script "tools/translatesieve" after configuring the namespace option(s). This script will translate the folder names in fileinto actions.

Alternate Mailbox Namespace

The alternate namespace allows a user's personal mailboxes to appear as if they reside at the same level as that user's INBOX as opposed to children of it. For example, if user "bovik" had a personal "work" mailbox, it would appear to user "bovik" as "work" instead of "INBOX.work" as it would in the standard namespace.

This configuration requires that a special prefix be used for shared folders (to distinguish them from personal folders) and for accessing other users' folders. By default, the prefix for shared folders is "Shared Folders" and the prefix for other users folders is "Other Users". For example, a shared folder "foo" in the standard namespace would be presented as "Shared Folders.foo" in the alternate namespace.

NOTE: All tools for administering the server, including admins using cyradm, always use the internal namespace.

Configuring the Alternate Namespace

To use the alternate namespace, turn on the altnamespace option in /etc/imapd.conf. The prefixes used for shared folders and other users folders can be changed from the defaults by setting the sharedrefix and userprefix options respectively.

UNIX Hierarchy Convention

The UNIX hierarchy convention uses the traditional UNIX separator character ("/") to delimit levels of the mailbox hierarchy instead of the netnews character ("."). For example, if user "bovik" had a personal "work" mailbox, it would appear to user "bovik" as "INBOX/work" in the standard namespace.

When the UNIX hierarchy convention is used, the "." character MAY be used in mailbox names, including user names. In order to maintain backwards compatibility with the internal namespace, all "." characters are translated to a benign character (currently "^") before any data is stored to disk. For example, if user "elmer.fudd" had a personal "rabbit.holes" mailbox, it would be stored as "user.elmer^fud.rabbit^holes" in the internal namespace. It is important to remember this phenomenon if/when reverting back to the netnews hierarchy convention.

Configuring the UNIX Hierarchy Convention

To use the UNIX hierarchy separator, turn on the unixhierarchysep option in /etc/imapd.conf.


Return



Sending Feedback on the Cyrus IMAP Server

Feedback on and fixes for the software or on the document may be sent to cyrus-bugs+@andrew.cmu.edu . Unfortunately, we can not guarantee a response but we'll try the best we can. As usual, a high quality and complete message helps us tremendously.

If you submit a patch, please send unified diffs (-u) if your diff program supports them, or context diffs (-c) if it doesn't. Plain diffs are very difficult to evaluate. GNU diff can do this.

When reporting problems, be sure to include the relevant information. For example, you must include:

You should also include:

NOTE: If you are able to connect to the imap server, all of this information can be gathered by using the version command in cyradm. If you can not use cyradm because you are having perl problems, you can connect using imtest and then run the following IMAP command:

The info-cyrus@andrew.cmu.edu mailing list exists for the discussion of this server and other Cyrus software; more information is available in the mailing-list document. You may get faster/more responses by posting to this list instead of to cyrus-bugs, as there are more readers here.


last modified: $Date: 2003/08/15 17:37:04 $
Return

Администрирование почтовых ящиков

Команда "cyradm"  (смотрите man-страницу  cyradm (8)) создает, удаляет, управляет ACL и квотами на почтовых ящиках. Для получения краткого обзора команд наберите "cyradm <host> ". Когда "cyradm" запуститься, Вы войдете в пользовательский режим и увидите приглашение в виде имени хоста и следующего за ним символа ">". Наберите "help ". Будет отображена следующая информация:
              			 
             		   
              			 
                           		
   
   createmailbox, cm        create a mailbox
   deleteaclmailbox, dam    delete an ACL on a mailbox
   deletemailbox, dm        delete a mailbox
   help                     get help on commands
   listaclmailbox, lam      list the ACL on a mailbox
   listmailbox, lm          list mailboxes
   listquota, lq            list quota on root
   listquotaroot, lqr, lqm  list quota roots on mailbox
   quit                     exit program
   renamemailbox, renm      rename a mailbox
   setaclmailbox, sam       set an ACL on a mailbox
   setquota, sq             set quota limits
Замечание:Необязательно запускать "cyradm" на самом IMAP-сервере, можно и на другой машине в сети.

Замечание:Если запустить "cyradm" на системе не использующей для аутентификации Kerberos, у Вас спросят Ваше имя и пароль до ввода любых команд "cyradm". Используйте опцию "-u " для указания имени пользователя.

Соглашение об именовании ящиков требует, чтобы главный ящик (inbox) для кого-либо назывался "user.<userid> ". Для создания ящика наберите:

   createmailbox user.<userid>

Например, для создания ящика для пользователя  "smith", наберите:
   createmailbox user.smith

Для ограничения "smith'у " почты до 10,000 kb наберите:
   setquota user.smith 10000

После создания inbox'а, пользователь сможет сам создавать дополнительные подъящики из почтовой программы. Если Smith создаст ящик "work" и ящик "play", полные имена ящиков будут выглядеть как:
   user.smith.work
   user.smith.play
   (Это для админа, а для Smith'а они будут выглядеть, как INBOX.work и INBOX.play
   -
   Прим.пер.)

Права доступа детально объясняются на man-странице  cyradm(1). Помните, что администратор должен установить для себя права на создание/удаление для ящика прежде чем он сможет удалить этот ящик:

   setaclmailbox <mail_box> <admin_userid> c
   deletemailbox <mail_box>

Как только Вы создали почтовые ящики, установку IMAP-сервера можно считать завершенной. Теперь необходимо настроить почтовый интерфейс, такой как  Pine или Mulberry, на работу с IMAP-сервером.



Аутентификация пользователей 

Введение

Cyrus IMAP Server для аутентификации пользователей использует библиотеку Cyrus SASL. Пожалуйста ознакомьтесь с документацией на Cyrus SASL для получения более детальной информации о SASL.

Аутентификационные механизмы

На момент написания этого руководства, основная библиотека Cyrus SASL поддерживает  такие SASL-механизмы, как CRAM-MD5, DIGEST-MD5, KERBEROS_V4 и GSSAPI. Cyrus IMAP, POP и LMTP также поддерживают STARTTLS используя сертификаты на стороне клиента и внешние(EXTERNAL) аутентификационные методы.

GSSAPI - это спецификация Kerberos 5. И еще, STARTTLS-сертификация на стороне клиента не была должным образом протестирована.

Когда STARTTLS разрешен, PLAIN SASL-механизм (если установлен) также будет доступен. Это нормально, потому что всеравно нельзя будет передать пароль открытым текстом по шифрованному соединению.

Протокол IMAP также поддерживает аутентификацию пользователей без использования SASL (спецификация). Это можно осуществить через команду 'LOGIN' (не путать с механизмом LOGIN в SASL). Команда IMAP LOGIN (как с PLAIN) посылает Ваш пароль серверу открытым текстом. В этом случае пароль все еще проверяется через библиотеку Cyrus SASL, хотя и никакой SASL-механизм при этом не используется.

POP-сервер может осуществлять APOP-аутентификацию. В этом случае Cyrus SASL должна быть собрана с ключем " --with-checkapop" ,  а пароли должны храниться в auxprop-базе (например: sasldb, auxprop, plugin).

Рекомендации

Настройка аутентификации

Cyrus SASL имеет множество опций, кторое могут быть настроены через использующее ее(библиотеку) приложение. Для настройки через imapd.conf, к нужной опции просто добавляется префикс  sasl_ (например: pwcheck_method будет выглядеть как  sasl_pwcheck_method).

/etc/sasldb2

Простейший метод аутентификации заключается в использовании аутентификационной базы libsasl, аккаунты в которой создаются с помощью утилиты "saslpasswd2". В настройках должно стоять "sasl_pwcheck_method: auxprop" и в SASL у sasldb должен быть установлен auxprop-модуль (это ставится по умолчанию). Удостоверьтесь, что Cyrus может прочитать из "/etc/sasldb2":

   chown cyrus /etc/sasldb2*

Shadow Passwords(Теневые пароли)

Реализация аутентификации пользователей из "/etc/shadow" более сложна , т. к. cyrus-пользователь не может чиатть файл теневых паролей. Также, это не полволит использовать механизмы shared secret. Чтобы осуществить это, необходимо настроить libsasl с поддержкой  saslauthd, и прописать в настройках "sasl_pwcheck_method: saslauthd". Библиотека SASL будет вызывать внешнююутилиту, запущенную от имени root'а, чтобы аутентифицировать пользователей.

Kerberos

Настройка Kerberos v4

Cyrus IMAP сможет поддерживаеть Kerberos v4 если библиотеку SASL собрать(откомпилировать) с поддержкой KERBEROS_V4.

Вам потребуется создать для сервера идентификатор Kerberos v4  и добавить ключ сервера в файл "srvtab". Cyrus-пользователь должен иметь право на чтение на этот файл. Сервер убдет иметь идентификатор Kerberos вида "imap.HOST@REALM", где "HOST " - первый компонент имени хоста сервера, а "REALM " - область Kerberos.

  1. Вот пример процедуры создания srvtabфайла для хоста с именем "foobar":
       ksrvutil -f /var/imap/srvtab add
    
    

    Ниже идет информация для запроса "ksrvutil". Необходимо вводить значения или нажимать  RETURN(Enter) . В этом примере имя хоста - "foobar", а имя области - "ANDREW.CMU.EDU".

       Name: imap
       Instance: foobar
       Realm: ANDREW.CMU.EDU
       Version number: 
       New principal: imap.foobar@ANDREW.CMU.EDU; version 0
       Is this correct? (y,n) [y] 
       Password: 
       Verifying, please re-enter Password: 
       Key successfully added.
       Would you like to add another key? (y,n) [y] n
    
  2. Если Вы планируете внедрять Kerberized POP, создайте идентификатор Kerberos "pop.HOST@REALM" и добавте ключ в файл "srvtab". Аналогично, если использовать LMTP через TCP, создайте Kerberos-идентификатор "lmtp.HOST@REALM" и добавте ключ в файл "srvtab ".

  3. Сделайте cyrus-пользователя владельцем файла "srvtab ":

       chown cyrus /var/imap/srvtab
    
    
  4. Добавте поцию srvtab в /etc/imapd.conf:
       srvtab: /var/imap/srvtab
  5. Протестируйте все это командой  imtest -m KERBEROS_V4. i mtest попытается авторизовать текущего Unix-пользователя независимо от текущей авторизации. Этого не бутет при использовании опции " -u" .

Разрешение проблем Kerberos_V4

Запустите программу "krbck"(находится в директории  imap) как cyrus-пользователь на IMAP-сервере. Эта программа продиагностирует неготорые конфигурационные ошибки Kerberos v4.

Настройка Kerberos v5

Cyrus IMAP сможет поддерживать Kerberos v5 если библиотека SASL собрана с поддержкой GSSAPI.

Вам нужно будет создать идентификатор Kerberos v5 для сервера. Ключи Kerberos v5 хранятся в "/etc/krb5.keytab".

  1. Добавте ключ "imap/hostname" используя "kadmin".
  2. Дайте cyrus-пользователю право на чтение "/etc/krb5.keytab ":
       chown cyrus /etc/krb5.keytab
    
    
  3. Проверте настройки с помощью  imtest -m GSSAPI. i mtest  попытается авторизовать текущего Unix-пользователя независимо от текущей авторизации. Этого не бутет при использовании опции " -u" .


Компилирование IMAP Server

После того, как Вы распаковали файлы из tar-архива, перейдите в директорию "cyrus-imapd-NNNN ", где  NNNN - номер версии. В ней находятся конфигурационные файлы и различные поддиректории. В директории в которйо находится файл  configure, выполните команду "./configure"(запустите скрипт configure) для настройки софта. Пожалуйста, читайте этот документ доконца, т. к.  у ./configure есть куча опций которые могут Вам пригодиться.

Обзор configure

Shell-скрипт "configure" попытается найти правильные занчения всех системо-зависимых переменных, которые могут потребоваться при компиляции. Он создает файл "Makefile" в каждой поддиректории пакета. В конце, он создаст: shell-скрипт "config.status" который Вы потом можете запустить для изменения текущей конфигурации(пересоздания), файл "config.cache" который хранит результаты всех тестов и позволяет ускорить процесс повторного создания конфигурации и файл "config.log" содержащий вывод компилятора (полезно, в основном, при отладке "configure").

Выполнение "configure" занимает некоторое время. Во время выполнения он выводит разные сообщения, говорящие о том, что он проверяет в данный момент.

Вы можете собрать пакет в другой директории(не в той, где находяться исходники). Это может понадобиться, например, при компиляции одновременно на нескольких компьютерах. Чтобы это осуществить, у Вас должна быть версия "make" которая поддерживает переменную "VPATH "(например GNU "make").Перейдите в директорию, где Вам нужно создать объектные и исполняемые файлы и запустите скрипт "configure ". "configure" автоматически проверит наличие исходников в директории, где находиться "configure " и в ".."(на уровень выше).

По умолчанию, "make install" установит файлы (кроме программ самого сервера) в "/usr/local/bin", "/usr/local/man ", и т. д.Вы можете переопределить префикс путей "/usr/local" используя у  "configure " опцию "--prefix=PATH".

Вы можете анзначить разные префиксы путей для архитектурно-зависимых и назависимых файлов. Для этого нужно использовать у  "configure " опцию "--exec-prefix=PATH", тогда пакет будет использовать путь  PATH как префикс для установки программ и библиотек. Документация и файлы с другими данными будут использовать регулярный префикс(configure сам его определит - Прим. пер.).

По умолчанию, "make install " установит программы самого сервера в "/usr/cyrus/bin". Вы можете определить префикс для этих программ отличный от "/usr/cyrus" с помощью опции "--with-cyrus-prefix=PATH".

Опции  configure

Ниже приведен список опций, которые могут быть использованы с  " configure ".

--help
Печать всех опций "configure" и выход(процесс настройки не начинается).

--with-auth=METHOD
Определяет аутентификационный (group membership) модуль для использования. Существующие в данный момент модули аутентификации:
unix
Unix-файлы /etc/passwd и /etc/group
krb
Kerberos (требует библиотеки Kerberos). По желанию, можно указать где находится  Kerberos v4 с помощью "--with-krb=DIR" ВАЖНО: Для поддержи Kerberos v4 требуется библиотека DES. Некоторые производители и распространители Kerberos, включая Solaris, не имеют такой поддержки, поэтому в таких системах это не может быть реализовано.
krb_pts
Доверия Kerberos с группой AFS PTserver'ов (требуется Kerberos и библиотеки AFS). При необходимости можно указать расположение библиотек AFS с помощью "--with-afs=PATH". Также требуется поддержка krb, как в вышесказанном случае.
Любой метод аутентификации с SASL может быть использован с любым авторизационным модулем.

--with-krb=PATH
Определяет где нахлдятся библиотеки Kerberos.

--with-com_err=PATH
Определяет где найти среду com_err.

--with-cyrus-group=USER
Определяет группу успользуемую для установки guid на программы. По умолчанию используется "mail".

--with-cyrus-prefix=PATH
Исменяет расположение ПО сервера. По умолчанию,  используется префикс  /usr/cyrus.

--with-cyrus-user=USER
Определяет userid, от имени которого Cyrus IMAP Server будет запускаться. По умолчанию "cyrus".

--with-dbdir=PATH
Определяет, где находятся библиотеки Berkeley DB.

--with-duplicate-db=DB
Определяет БД, которая будет использоваться как юаза двойной доставки. По умолчанию "db3_nosync"

--with-mboxlist-db=DB
Определяет БД, в которой будет храниться списой почтовых ящиков. По умолчанию "db3"

--with-seen-db=DB
Определяет БД для хранения информации о состоянии. По умолчанию "flat"

--with-subs-db=DB
Определяет БД для хранения списка подписок. По умолчанию "flat"

--with-tls-db=DB
Определяет БД, которая будет использоваться, как TLS-кэш. По умолчанию "db3_nosync"

--with-idle=METHOD
Определяет используемый метод IMAP IDLE . В данный момент есть мледующие методы IDLE:
idled
Используется демон IDLE. Демон IDLE слушает сокет UNIX и ждет сообщения от lmtpd/imapd/pop3d на обновление почтового ящика. Демон посылает сигнал на обновление соответствующим imapd.
poll
Переодически заставляет ящики обновляться.
no
Отключает IMAP IDLE.
По умолчанию "poll".

--with-lock=METHOD
Определяет используемый метод блокировки. Существуют следующие методы:
flock
блокировка flock()
fcntl
блокировка fcntl()
По умолчанию используется "fcntl" если функция "fcntl()" существует, усли нет, то используется "flock ".

--with-openssl=PATH
Определяет, где искать библиотеки OpenSSL.

--with-egd-socket=FILE
Определяет сокет дял соединения с  Entropy Gathering Daemon.

--with-perl=PATH
Определяет, где лежат библиотеки Perl'а (полный путь, включающий имя бинарника).

--with-sasl=PATH
Определяет путь к директории содержащей библиотеки (.../lib) и включаемые модули (.../include ) для libsasl.

--with-statedir=PATH
Определяет директорию используемую для связи с различными демонами. Поумолчанию "/var".

--with-libwrap=PATH
Определяет, где искать библиотеку TCP wrappers.

--with-ucdsnmp=PATH
Определяет, где искать библиотеку SNMP.

--with-zephyr=PATH
Определяет, где искать библиотеку Zephyr(для notifyd).

--enable-annotatemore
Включает поддержку расширения ANNOTATEMORE (mailbox/server annotations).

--enable-fulldirhash
Включает улучшенную схему хеширования, при которой хешируется все имя пользователя, вместо только одной первой буквы.

--enable-listext
Включает поддержку расширения LISTEXT.

--enable-murder
Включает поддержку IMAP Murder.

--enable-netscapehack
Включает поддержку для расширения X-NETSCAPE (администраторские URL'ы).

--disable-sieve
По умолчанию, поддержка Sieve включена. Используйте --disable-sieve для запрещения компилякии библиотеки Sieve и полного отключения поддержки Sieve.

--disable-cyradm
Не компилировать админского клиента(программу)  cyradm .

--disable-server
Не компилировать программы сервера IMAP.

Запустите " configure --help" чтобы узнать о дополнительных опциях.

Некоторые системы требуют для компиляции и линковки требуют специфических опций, о которых скрипт "configure" ничего незнает. Вы можете указать их "configure " через установку(задание) значений переменным окружения. Используя Bourne-совместимый шел, Вы можете сделать это прямо из командной строки:

   CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
Или в системе, где имеется программа "env " :
   env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
"make " -переменные, которые Вы можете использовать с "configure ":
CC
Компилятор C.
По умолчанию "cc", или "gcc", если "gcc" присутствует в переменной PATH.
(Для "CC", любое значение переменных окружения  перекроет значение, корое определяет "configure"(Т.е. оно более приорететно -При. пер.).)
CFLAGS
Отладочные и оптимизационные опции для компилятора C.
CPPFLAGS
Главный файл ищет директорию ("-IDIR") и любые другие опции препроцессора C и компилятора. Если это значение не установленно через переменную окружения на момент запуска "configure ", то используется пустое значение.
LDFLAGS
Исключающие("-s") и любые другие опции линкера(программа link). Если это значение не установленно через переменную окружения на момент запуска "configure ", то используется пустое значение.
 
DEFS
Конфигурационные опции, в виде "-Dfoo -Dbar ..."
LIBS
Библиотеки для линковки, в виде "-lfoo -lbar ..."
(Для "DEFS" и "LIBS", любое значение взятое из среды  добавляется к значению определенным скриптом "configure ")
Если у Вас есть какие-нибудь мысли по поводу сборки пакета, мы будем благодарны, если Вы выясните как улучшить "configure ". После этого, пожалушста, пошлите нам патч! Инструкции по этим вопросам находятся на странице с  обратной связью .

Файл "configure.in" используется как шаблон для создания "configure" с помощью вызова программы "autoconf". Вым это понадобится только в том случае, если Вы захотите пересоздать "configure" используя более новую версию "autoconf".

После успешного выполнения "configure ", выполните следующие команды:

   make depend
   make all CFLAGS=-O

Если нужно, Вы можете переопределить переменные "makeCFLAGS и LDFLAGS следующим образом :
   make all CFLAGS=-O2 LDFLAGS=-s



Настройка IMAP-сервера

Этот раздел описывает запуск shell-скриптов и изменение конфигурационных файлов после запуска "configure" и "make ".
  1. Создаются пользователь и группа для Cyrus-подсистемы. В этом документе приведены примеры с использованием пользователя "cyrus" и группы "mail", хотя они могут быть любые другие. Если будет использоваться имя пользователя отличное от "cyrus ", то оно должно быть задано прараметнром "--with-cyrus-user=" скрипта "configure". Если используемая группа отлична от "mail ", то она должна быть указанна в параметре "--with-cyrus-group=" скрипта "configure".

  2. После того, как Вы залогинились под root'ом , можно ставить софт.
       make install
    
    
    Убедитесь, что Вы правильно задали параметр "--with-cyrus-prefix" (по умолчанию, "/usr/cyrus/bin").

  3. Cyrus IMAP Server использует 4.3BSD syslog, который разделяет сообщения на уровни и категории. С помощью "man syslog" проверьте, количество аргументов функции "openlog() ". Если нет, замените файлы "syslogd" и "syslog.conf" файлами расположенными в директории "syslog ".
       mv syslogd /etc/syslogd
       mv syslog.conf /etc/syslog.conf
    
    
    Если Вы не скопируете файл "syslog/syslog.conf" в директорию "/etc", убедитесь, что поддерживается "local6.debug ". Файл должен включать такую строку:
       local6.debug  /var/log/imapd.log
    
    Вероятнее всего, Вы захотите вести журнал сообщений от SASL, тогда должна быть такая строка:
       auth.debug /var/log/auth.log
    
    После установки и тестирования, Вы, возможно,  захотите изменить компонент ".debug" на что-нибудь менее звучное. Создайте log-файлы:
       touch /var/log/imapd.log /var/log/auth.log
    
    
  4. Создйте файл "/etc/imapd.conf". Вот пример "imapd.conf " с минимальным количеством параметров:
       configdirectory: /var/imap
       partition-default: /var/spool/imap
       admins: curtj abell
       sasl_pwcheck_method: saslauthd
    
    Для получения описания всех параметров в этом файле, обращайтесь к man-странице imapd.conf(5) man page. (Помните, что этот файл передает(экспортирует) некоторые некоторые значения в libsasl, самый важный из них - pwcheck_method. В этом примере пользователи аутентифицируются через демон saslauthd, для которого существует множество различных способов управления .)

    ЧИТАЙТЕ MAN-СТРАНИЦУ  imapd.conf(5) . Есть опции, значания по умолчанию которых могут Вам не понравиться.

    Помните, что  каждодневные пользователя не должны быт администраторами. Админы имеют полномочия, которых не может быть у простых пользователей и пока сервер позволяет им получать почту будут возникать некоторые проблемы, если админы используются как простые пользователи. Вы , как администратор, также  не должны  читать почту. У Вас должны быть разные аккаунты для чтения почты и администрирования. Это особенно важно при использовании опции  altnamespace , т.к. админы  всегда представлены в стандартом (внутреннем) именовании.

  5. Создайте конфигурационную директорию, определяемую опцией "configdirectory " в "imapd.conf". Конфигурационная директория своей концепцией похожа на директорию "/usr/lib/news ". Там храниться информайия о IMAP-сервере в целом.

    В примерах этого документа используется конфигурационная директория "/var/imap". Владельцем этой директории должен быть cyrus-пользователь и cyrus-группа, остальные пользователи не должны иметь никакого доступа.

       cd /var
       mkdir imap
       chown cyrus imap
       chgrp mail imap
       chmod 750 imap
    
    
  6. Создайте директории раздела по умолчанию, определенного в файле "/etc/imapd.conf ".

    В примерах этого документа используется директория раздела по умолчанию "/var/spool/imap ":

       cd /var/spool
       mkdir imap
       chown cyrus imap
       chgrp mail imap
       chmod 750 imap
    
    
    Концепкия директории раздела похожа на  /var/spool/news . Там хранатся почтовые ящики. В отличие от большинства netnews-систем, Cyrus позволяет иметь более одного раздела. Не используйте "news", как имя раздела, т.к. это имя зарезервированно для теелконференций(netnews).
  7. Если Вы хотите использовать Sieve, и Вы не настраивали доставку для просмотра домашних директорий (читайте man-страницу по  imapd.conf ), создайте Sieve-директорию:
       cd /usr
       mkdir sieve
       chown cyrus sieve
       chgrp mail sieve
       chmod 750 sieve
    
    
  8. Войдите как Cyrus-пользователь(можно и просто от его имени - Прим. пер.) и воспользуйтесь утилитой "tools/mkimap" чтобы создать остальную часть директорий (поддиректории директорий, которые Вы уже создали). Помните, если Вы собрали cyrus с параметром  --enable-fulldirhash , то вместо "tools/mkimap" нужно использовать "tools/rehash ".
       su cyrus
       tools/mkimap
       exit
    
    
    Если Perl'нет, то несложно (но долго) создать эти директории вручную.

  9. LINUX-СИСТЕМЫ ИСПОЛЬЗОВАНИЕ ТОЛЬКО EXT2FS: Заставьте пользователя, квоту и директории раздела обновляться синхронно. Если этого не сделать это может вызвать повреждение данных и/или потерю сообщений полсе сбоя. К сожалению, если так поступать, то это может привести к серьезному падению производительности. Если Вы используете на Linux'е более новую файловую систему чем ext2fs, этот шаг выполнять необязательно. (Использование ext3 в любом режиме - безопастно.)
       cd /var/imap
       chattr +S user quota user/* quota/*
       chattr +S /var/spool/imap /var/spool/imap/*
    
    
    Также заставте директорию очереди почтового демона обновляться синхронно. Следующий пример для sendmail:
       chattr +S /var/spool/mqueue
    
    

  10. Для вклбчения поддержки STARTTLS, читайте ниже как настроить OpenSSL .

  11. Добавте следующие строки в файл "/etc/services ", если их там нет.
       pop3      110/tcp
       imap      143/tcp
       imsp      406/tcp
       acap      674/tcp
       imaps     993/tcp
       pop3s     995/tcp
       kpop      1109/tcp
       sieve     2000/tcp
       lmtp      2003/tcp
       fud       4201/udp
    

  12. Удалите записи в "/etc/[x]inetd.conf ". Любые строки относящиеся к imap, imaps, pop3, pop3s, kpop, lmtp и sieve должны быть удалены из  /etc/[x]inetd.conf и [x]inetd должен быть перезапущен.

Настройка Master-процесса

  1. Выбирете конфигурацию из директории  master/conf :
    small.conf
    "голый" вервер с поддержкой IMAP и POP
    normal.conf
    сервер с поддержкой IMAP, POP, SSL wrapped-версия и протокол управления скриптами Sieve
    prefork.conf
    Такой же конфиг, как и предыдущий, но с некоторым количеством "готовых" дочерних процессов процессами для повышения производительности. (Т.е. при запуске сервер сразу создает какое-то число процессов каждый из которых будет ждать подключения клиента. Один клиент на один процесс. При подключении клиента время на выполнение fork() не тратиться - Прим. пер.)
    backend-cmu.conf
    Наша конфигурация (для Murder Backend / типичного IMAP-сервера)
    frontend-cmu.conf
    Наша конфигурация (для серверов Murder Frontend)

    Для использования  normal.conf, выполните:

       cp master/conf/normal.conf /etc/cyrus.conf
    
    

    По желанию, Вы можете отредактировать  /etc/cyrus.conf для разрешения или запрета определенных сервисов, или настроить число "готовых" процессов . Убедитесь, что не удалили записи, помеченные  как. требуемые 

  2. Сделайте так, что бы  "/usr/cyrus/bin/master"  запускался от имени root'а во время запуска всей системы. Это позволит серверу создать сетевой сокет и получить привилегии root'а. До перезагрузки системы Вы можете запустить master-процесс вручную:
       /usr/cyrus/bin/master &
    
    

  3. Контроль за master-процессом осуществляется через файл imapd.log. Master-процесс никогда не должен завершаться самостоятельно, но вы можете остановить почтовую систему посылая соответствующий сигнал через  kill.

Настройка Mail Transfer Agent(MTA)

Для того, что бы почта шла в Cyrus, Вы должны настроить ваш MTA (Sendmail, Postfix, Exim, etc) на использование LMTP.

Настройка  Sendmail

Сгенирируйте конфигурационный файл sendmail, который заставит доставлять локальную почту IMAP-серверу. Читайте файл  cf/README в дистрибутиве Sendmail о том как создавать конфигурационные файлы. В этом файле перечислены переменные, которые могут быть использованы для настройки определений mailer'ов (mailer definition) перечисленных ниже.

Следующие конфигурации предпологают, что вы используете сервис  lmtpunix  и однин из конфигов  cyrus.conf обсужденных выше.

Настройка  Postfix

Исходники Postfix'а распространяются с файлом "README_FILES/LMTP_README". Даже если Вы используете бинарный(уже собранный) дистрибутив Postfix, былобы нелишним скачать исходники Postfix'а. Вы получите нетолько вышеупомянутый файл, но и большое количество других файлов "readme" files и примерных конфигов.

Один важный момент, который Вы не должны упускать - это UID и GID Postfix'а. Как сказанно в документе Postfix'а "INSTALL" , Вы должны создать новый аккаунт который не разделяет свой UID и GID с любым другим пользовательским аккаунтом. Это делается из соображений безопастности. Если Вы установили Postfix с GID  "mail", Вам нужно будет выбрать другой GID для Cyrus. Смотрите описание конфигурационных опций Cyrus'а "--with-cyrus-user" и "--with-cyrus-group". (Это было наиболее критично когда использовался Cyrus'овский "deliver ", но всеравно было бы неплохо придерживаться этой политики.)

Другой момент заключается в определении местонахождения команды "sendmail". На одних платформах это может быть "/usr/sbin/sendmail", на других, "/usr/lib/sendmail". Cyrus должен знать где находиться эта команда. За детелями обращайтесь в  Installing Sieve .

Если Вы пользуетесь сервисом  lmtpunix как в примерах  cyrus.conf описанных выше, конфигурационный файл Postfix  "/etc/postfix/main.cf " должен иметь такую строку:

  mailbox_transport = lmtp:unix:/var/imap/socket/lmtp

Естественно, оба, Postfix UID и Cyrus UID, должны иметь соответствующий доступ к указанному сокету.

Начиная с  Postfix snapshot-20010222, Вы можете улучшить эффективность LMTP-доставки через "mailbox_transport", поместив следующие строки в файл "/etc/postfix/main.cf":

  local_destination_recipient_limit = 300
  local_destination_concurrency_limit = 5

Конечно, Вы должны приспособить эти настройки в соответствии с вашими аппаратными требования. Ограничение числа получателей может хорошо сочитаться с возможностью Cyrus'а хранить сообщения в единственном экземпляре. Лимит конкурирующих подключений может быть использован для контроля количества одновременных LMTP-сессий к хранилищю сообщений в Cyrus'е.

Дополнительные примеры включены в файл Postfix "README_FILES/LMTP_README".

Настройка  Exim 4

Сгенерируйте гонфиг Exim'а который позволит осуществлять доставку локальной почты IMAP-серверу. Читайте документацию к Exim'у о том, как создать конфиг.

Cyrus разработан для использования как black-box-сервер -- т.е. никаких локальных(системных) пользовательских аккаунтов. Из-за этого, Вы должны будете определить следующий "router":

Следующие "transports" подразумевают их использование их с сервисом  lmtpunix или lmtp  из файла cyrus.conf описанного выше.

Для более продвинутой настройки (такой как верификация адресов и т.д.), читайте доки по Exim и примеры конфигов.

SSL, TLS и OpenSSL

Transport Layer Security (TLS), является стандартизированной версией стандарта Secure Sockets Layer (SSL v3). IMAP может использовать две различные версии TLS/SSL: STARTTLS и SSL wrapped сессии.

В STARTTLS, клиент подключается к порту IMAP и затем посылает STARTTLS-команды, которые инициируют TLS-обмен. В настоящий момент это поддерживается Cyrus IMAP Server'ом, если тот собран с  OpenSSL.

Альтернатива: SSL-wrapped-соединение, клиент подключается к другому порту ("imaps ") и устанавливает SSL-сессию до начала IMAP-протокола. Это также поддерживается Cyrus IMAP Serve'ом, если тот собран с OpenSSL.

Оба, TLSи SSL, требуют наличие серверного ключа и сертификата. По желанию, помимо установки безопастного соединения, TLS может аутентифицировать клиентов.

Настройка Cyrus с OpenSSL

  1. OpenSSL требует сертификата и ключа в PEM-формате. Вы можете создать закрытый ключ сервера и сертификат с собственной подписью. Далее, мы создаем собственный ключ для машины " foobar.andrew.cmu.edu", затем помещаем и сертификат и ключ в файл "/var/imap/server.pem".

    Пожалуйста, не используйте следующюю информацию для OpenSSL. Вместо нее введите нужную информацию для Вашей организации (т.е. НЕ Carnegie Mellon University в имени организации и т.д.).

    openssl req -new -x509 -nodes -out /var/imap/server.pem -keyout /var/imap/server.pem -days 365
    Using configuration from /usr/local/lib/openssl/openssl.cnf
    Generating a 1024 bit RSA private key
    .............+++++
    ......................+++++
    writing new private key to '/var/imap/server.pem'
    -----
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:Pennsylvania
    Locality Name (eg, city) []:Pittsburgh
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:Carnegie Mellon University
    Organizational Unit Name (eg, section) []:Andrew Systems Group
    Common Name (eg, YOUR name) []:foobar.andrew.cmu.edu
    Email Address []:
    
  2. Будьте уверены, что сделанные файл(ы) с ключами могут быть прочитаны Cyrus-пользователем. Например: chown cyrus /var/imap/server.pem
  3. Добавьте следующие строки в файл  /etc/imapd.conf, чтобы указать серверу где имкать файлы ключей и сертификатов  (используется для ВСЕХ сервисов):
    tls_cert_file: /var/imap/server.pem
    tls_key_file: /var/imap/server.pem
    
    По желанию, Вы можете использовать разные файлы ключей и сертификаты для каждого сервиса:
    tls_imap_cert_file: /var/imap/imap-server.pem
    tls_imap_key_file: /var/imap/imap-server.pem
    
    tls_pop3_cert_file: /var/imap/pop3-server.pem
    tls_pop3_key_file: /var/imap/pop3-server.pem
    
    tls_lmtp_cert_file: /var/imap/lmtp-server.pem
    tls_lmtp_key_file: /var/imap/lmtp-server.pem
    
    tls_sieve_cert_file: /var/imap/sieve-server.pem
    tls_sieve_key_file: /var/imap/sieve-server.pem
    
    Это полезно когда используются различные имена хостов для разных сервисов (например через виртуальные хосты или DNS CNAME). При отсутствии в любом из сервисов определенной опции, будет использоваться значение глобальной опции. Значение  запрещающие сертификат или ключевой файл для какого-либо сервиса отключит SSL/TLS для этого сервиса.

    Если у Вас есть Certificate Authority (CA), Вы можете сгенерировать запрос на подпись сертификата и послать его на обработку Вашему CA.

    По умолчанию, Cyrus будет кэшировать SSL/TLS-сессии до 24 часов. Используя опцию  tls_session_timeout  в imapd.conf, кэширование сессии может быть отключено (0) или сокращен период хранения.

  4. Вы можете протестировать STARTTLS используя imtest:
    imtest -t "" foobar.andrew.cmu.edu
    
    

Сертификаты на стороне клиента

Клиентские сертификаты формируются несколько сложнее, чем сертификаты серверов. Вам нужен CA (certificate authority) и нужно сгенерировать сертификат подписанный CA. STARTTLS в Sendmail и других MTA have подобные проблемы. С.м. Claus Assman's page

Вы можете использовать сертификат с собственной подписью как CA для клиентского сертификата. Чтобы это сделать, попробуйте следующее:

TODO: write me!

К сожалению, нет стандарта позволяющего конвертировать клиентские аутентификационные DN (distinguished name) в аутентификационные имена SASL.

Альтернативное именование и соглашение об иерархии UNIX

Если Вы будите использовать альтернативное именование и/или соглашение об иерархии UNIX, то прочтите  altnamespace.html.



Installing The Cyrus Murder

Note that Cyrus Murder is still relatively young in the grand scheme of things, and if you choose to deploy you are doing so at your own risk. Many of the failure modes can be difficult to track without a detailed understanding of the mupdate protocol and IMAP in general, and thus even considering a deployment is not for the faint at heart.

At the same time, we are using it successfully in production at Carnegie Mellon.

Introduction & Assumptions

This document is intended to be a guide to the configuration of a Cyrus IMAP Aggregator, aka Cyrus Murder. It is recommended that you review this document to be familliar with the concepts at work. This document is a work in progress and is at this point incomplete.

This document assumes that you have successfully been able to setup atleast one Cyrus IMAP server. This server will become your first backend server. It also assumes that you are familliar with the administration and day to day operations of the Cyrus IMAP server and the SASL authentication library. If you feel uncomfortable with this, please refer to the rest of the documentation first.

There is a diagram that shows the interactions of the various components of the Cyrus Murder which may be helpful in understanding the "big picture".

Installation

You will need to build Cyrus IMAPd with the --enable-murder configure option. This builds the proxyds and the associated utilities.

Requirements

Configuring the MUPDATE Master

The mupdate master server needs to be running the mupdate service in master mode. Note that you can have the MUPDATE master be one of your frontend machines, just do not configure a slave mupdate process on this machine.

To configure an mupdate master, you will want a cyrus.conf that includes a line similar to the following in the SERVICES section:

  mupdate       cmd="/usr/cyrus/bin/mupdate -m" listen=3905 prefork=1
Note the "-m" option to tell mupdate that it should start in master mode.

You will also need to configure atleast a skeleton imapd.conf that defines the configdirectory, a bogus partition-default and the admins that can authenticate to the server. Note that slave mupdate servers as well as the backend servers will need to be able to authenticate as admins on the master. Here is a very simple imapd.conf for a master server:

configdirectory: /imap/conf
partition-default: /tmp

admins: mupdateslave1 backend1
You will also need to configure SASL to properly allow authentication in your enviornment.

Setting up the backends to push changes to the MUPDATE Master

On the backends, configuration to be a part of a murder is easy. You just need to configure the backend to be a part of the murder. To do this, set the mupdate_server option in imapd.conf. Depending on what authentication mechanisms you are using, you may also want to set some or all of the following: Once these settings are successfully made, any mailbox operation on the backend will be sent to the mupdate master for confirmation and entry into the mupdate database.

You will also want to configure atleast one user/group using the proxyservers imapd.conf option. This user should not be an administrator, since this means that anyone who can get ahold of your proxy servers now has full administrative control on your backend. Example:

admins: cyrus
proxyservers: murder
Keep in mind that you will need to create the proxy user(s) and be sure that they can authenticate to the backend as well.

Importing the database from the backend

Importing the current mailboxes database is easy, as there is a ctl_mboxlist option to do so. To do the first synchronization, simply change to the cyrus user, and issue a ctl_mboxlist -m.

Note that you may wish to issue a ctl_mboxlist -mw first to be sure you understand all the operations that this command will perform, sicne it does require tha all mailboxes are unique in the murder namespace.

If everything is configured properly, the mailbox database of the current host will dump to the mupdate master. If there are problems, the most likely cause is a misconfiguration of the authentication settings, or that mupdate might not be running on the master. Using mupdatetest may be helpful in this case (it establishes an authenticated connection to the mupdate server, if it can).

It is also useful to have the backends automatically resync the state of their local mailboxes database with the master on start up. You can configure this by adding the following to the START section of cyrus.conf on the backends:

  mupdatepush   cmd="ctl_mboxlist -m"
This will perform synchronization with the mupdate master each time the backend restarts, bringing the mupdate database up to date with the contents of the backend (and performing ACTIVATE and DELETES as needed to do so).

Warning: If somehow a mailbox exists on two (or more) backend servers, each time one of them synchronizes its database that backend server will become authoritative. Though this should not happen during normal operation of the murder (because of the consistancy guarantees of the MUPDATE protocol, and the fact that mailbox operations are denied if the mupdate master is down), it is possible when first creating the mupdate database or when bringing a new backend server into the murder.

Configuring the frontends

Configuring the frontends is a two step process. First, you want to set mupdate_server (and friends) as you did for the backends above. However, because the frontends only talk to the mupdate master via a slave running on the local machine, you will also need to set up a slave on the same machine, in the SERVICES section of cyrus.conf, like so:

  # mupdate database service - must prefork atleast 1
  mupdate       cmd="mupdate" listen=3905 prefork=1 
Note that as this is a threaded service, you must prefork atleast 1 of them so that the database can be synchronized at startup. Otherwise, the service will not start running until after you recieve an mupdate client connection to the slave (which is not a recommended configuration at this point).

You will also want to change all of your imapd entries to be proxyd, and all of your pop3d entries to be pop3proxyd. That is, you will probabally have a SERVICES section that looks more like this now:

  mupdate       cmd="/usr/cyrus/bin/mupdate" listen=3905 prefork=1 

  imap          cmd="proxyd" listen="imap" prefork=5
  imaps         cmd="proxyd -s" listen="imaps" prefork=1
  pop3          cmd="pop3proxyd" listen="pop3" prefork=0
  pop3s         cmd="pop3proxyd -s" listen="pop3s" prefork=0
  kpop          cmd="pop3proxyd -k" listen="kpop" prefork=0
  sieve         cmd="timsieved" listen="sieve" prefork=0
  lmtp          cmd="lmtpproxyd" listen="/var/imap/socket/lmtp" prefork=0
Note that timsieved does not need a proxy daemon, the managesieve protocol deals with the murder with referrals to the backends internally.

Additionally, you will need entries in imapd.conf to indicate the proxy auth name and passwords (if you are using a SASL mechanism that requires them) to the backends, for example, if your backends are mail1.andrew.cmu.edu and mail2.andrew.cmu.edu with passwords of foo and bar, and an auth name of murder:

mail1_password: foo
mail2_password: bar
proxy_authname: murder
If your SASL mechanism does not require authnames or passwords (e.g. KERBEROS_V4), then this is not required. Note that we used the same authname as the configured in the proxyservers line in the backend's imapd.conf above.

When you start master on the frontend, a local mailboxes database should automatically synchronize itself with the contents of the mupdate master, and you should be ready to go. Your clients should connect to the frontends, and the frontends will proxy or refer as applicable to the blackend servers.

Additional backend configuration

If your authentication system requires usernames, passwords, etc, to authenticate (e.g. it isn't Kerberos), then you will also need to specify proxy_authname (and friends) in the backend imapd.confs as well. This is so that the backends can authenticate to eachother to facilitate maibox moves. (Backend machines will need to be full admins).

Delivering mail

To deliver mail to your Murder, configure your MTA just as you did before, but instead of connecting directly to lmtpd, it should connect to lmtpproxyd. You can connect to the lmtpproxyd running on the frontend machines, or you can install master and lmtpproxyd on your SMTP servers.

Administration

Keeping the database synced

Consistancy in the database is maintained by pushing the current status of the backends to the master, and having the frontends stay up to date with the master's database. Since the frontends resync themselves entirely when they startup, downtime should not at all be a problem. (While they are up they should be continously recieving database updates, as well as when they lose connection to the master, they will try to reconnect and resync their database upon reconnection)

Provided that the namespace of the backend servers is kept discrete (with no mailboxes existing on the same server), it is not a big deal to resync the mupdate master using ctl_mboxlist -m. If two servers do have the same mailbox, this will need to be resolved before database consistancy can be guranteed.

Moving Mailboxes between backends

There is currently no 100% foolproof way to do this, however, if you issue a rename command to a frontend (as you would to move a mailbox between partitions), and replace the partition name with the name of the new backend, it will move the mailbox to the indicated backend. You can also use the format backend.domain.com!partition to move to a specific partition (otherwise the default partition will be used). In cyradm, this looks like:

cyrus.andrew.cmu.edu> rename user.bcyrus user.bcyrus mail2.andrew.cmu.edu!u2
Note that since seen state is stored per-user, it is possible that when moving a shared mailbox users will have strange effects. The general rule is that moving an INBOX will move the entire user (including all sub-mailboxes to the INBOX, and seen state, and subscriptions, and sieve scripts, etc). The seen state is merged with the seen state on the new backend, so that no data is lost (seen state is also the only part left behind on the source backend). In the case of any other mailbox, however, only that individual mailbox is moved. If it is a quota root, the new quota root is instated on the new server, but otherwise quotas can appear to be violated, since each backend only takes care of its own quota.

In general, its better to leave trees of mailboxes on the same server, and not move submailboxes of inboxes between servers.

Adding additional backend servers

This is very easy to do, simply configure an empty backend server and set its mupdate_server parameter to point at the mupdate master. Then, issue mailbox creates to it as you would any other backend server.

Backups

xxx, need to write stuff. You don't need to really backup the data on the mupdate master or slaves, since this data can all be generated directly from the backends quite easily.

Gotchyas

Troubleshooting & when things go wrong

References


last modified: $Date:
Performance Notes Performance issues for you to consider. If you never expect to have more than 100 simultaneous users, chances are any hardware you have will be fine. If you plan on having thousands or more users, please be sure to review this section.

If your configuration directory is not /var/imap, adjust accordingly.

In general, there's no magic bullet for performance. It depends on your hardware, your operating system, and how your users use the system. In general, an imapd process takes up anywhere from 256 Kbytes of memory to 512 Kbytes when it is first fired up. CPU has not been a big deal, but it may become more important as the imap sessions are encrypted and now that searching may be more frequent. Disk I/O is probably the most important and having a hardware RAID subsystem with an amount of write-back cache would be a good thing.

Finally, if you are talking about less than 100 interactive users it is likely that any relatively modern hardware can support it. If you are talking about having more than 1000 interactive users, you should know how to predict your utilization, go overboard on hardware, be willing to suffer growing pains, or be able to hire someone that can help.

There are a number of good performance tuning articles out for Solaris by Adrian Cockcroft. Go to your favorite search engine and look for his name.


last modified: $Date: 2003/01/02 19:23:11 $

Требования

Требования

Следующие программы и/или пакеты являются  необходимыми.

Следующие программы и/или пакеты требуются для специальных возможностей. Если у Вас их нет, некоторые фенкции IMAP-сервера будут недоступны.

Следующие программы и/или пакеты рекомендуются:



Установка Sieve

Этот раздел описывает как собрать Cyrus с поддержкой sieve. Если указать " --disable-sieve" при запуске  ./configure, Вы НЕ соберете сервер с поддержкой sieve.

Краткий ввод в Sieve доступен на  Cyrusoft International.

Настройка исходящей почты

Некоторые действия Sieve (перенаправление, vacation) могут посылать исходящюю почту.

Вы должны быть уверенны, что "lmtpd" может посылать исходящие сообщения. По умолчанию для отправки сообщений используется используется "/usr/lib/sendmail ". Это можно изменить добавив такую строку:

   sendmail: /usr/sbin/sendmail
в Ваш "/etc/imapd.conf". Если Вы используете Postfix или другой MTA, имейте в виду, что sendmail, указанный в "/etc/imapd.conf" должен быть Sendmail-совместимым.

Управление Sieve-скриптами

Т.к. Cyrus базируется на понятии закрытого сервера, обычные пользователи могут управлять Sieve-скриптами только через утилиту "sieveshell ".

Если, по каким-то причинам, Вы храните домашние каталоги пользователей на сервере, Вы можете использовать опцию "sieveusehomedir " и хранить sieve-скрипт в домашнем каталоге пользователя в "~/.sieve".

Тестирование sieve-сервера

  1. Sieve-сервер "timsieved" испольузется для транпортировки пользовательских Sieve-скриптов в закрытый IMAP-сервер. Это несовместимо с опцией "sieveusehomedir". Демон назван в честь одного из авторов, Тима Мартина, который очень хотел, чтобы что-нибудь в дистрибутиве Cyrus было названо в честь него.

  2. Из вашего "нормального" аккаунта подключитесь через telnet к sieve-порту сервера который Вы настраиваете:
       telnet foobar sieve
    
    
    Если сервер запущен, Вы получите сообщение наподобие следующего:
       Trying 128.2.10.192...
       Connected to foobar.andrew.cmu.edu.
       Escape character is '^]'.
       "IMPLEMENTATION" "Cyrus timsieved v1.1.0"
       "SASL" "ANONYMOUS PLAIN KERBEROS_V4 GSSAPI"
       "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress regex"
       OK
    

    Любое сообщение не похожее на это будет говорить о проблеме. Удостоверьтесь, что все аутентификационные методы, которые Вам нужны, перечисленны. Этот список должен быть идентичен тому списку, который выдавал "imapd" ранее(в придыдущем разделе - Прим.пер.). Затем разорвите соединение, набрав "logout".

  3. Далее тестируется аутентификация на sieve-сервере. Для этого запустите утилиту "sieveshell ". Вы должны указать сервер. Если Вы запускаете утилиту с другой машину без записи "sieve" в "/etc/services", будет использоваться 2000 порт.
      "sieveshell foobar"
        Please
        enter your password: ****** >
         quit
    
    В случае проблемы появилось бы сообщение "Authentication failed " с описанием.

  4. Далее Вы должны попробывать поместить на сервер sieve-скрипт. Для этого создайте файл с именем "myscript.script" с нижеследующими строками. Замените "foo@example.org" на email-адрес с которого Вы можете отправлять почту, но не тот с которым Вы работаете в данный момент.
      require ["reject","fileinto"];
    
      if address :is :all "From" "foo@example.org"
      {
        reject "testing";
      }
    
    Для того чтобы поместить этот скрипт на сервер выполните следующюю команду:
      "sieveshell foobar"
        Please enter your
        password: ****** > put myscript.script
         > activate
         myscript >
         quit
    
    Ваш скрипт будет помещен на сервер и станет активным.

  5. Протестируйте сам скрипт. Отправте сообщение на адрес на адрес с которым Вы работаете с адреса указанного в sieve-скрипте. Сообщение должно быть отклонено.



SNMP-Мониторинг

TODO: конец этого раздела. Большая чать этого раздела перемещена во внешнюю доку по CySNIIP.

Cyrus использует вспомогательный процесс под названием "tugowar", названный так потому что он использует модель push-pull. Различные компоненты почтовой системы Cyrus помещают(push) данные в  tugowar,   tugowar, в свою очередь, слушает SNMP-запросы (удаленные клиенты бурут у него данные(pull)).

Настройка tugowar

Тестирование демона tugowar

Экспорт данных SNMP



Тестирование IMAP-сервера

Для тестирования IMAP-сервера, перезагрузитесь и и выполните следующие шаги (все примеры используют имя "foobar" как имя IMAP-сервера). Перечень рекомендаций по решению распространенных проблем возникающих при инсталляции можно прочитать на    http://asg.web.cmu.edu/cyrus/imapd/install-FAQ.
  1. Из Вашего "нормального" аккаунта, подключитесь с помощью telnet'а к IMAP-порту на сервере где все настраивалось:
       telnet foobar imap
    
    
    Если сервер запущен, Вы получите такое сообщение:
       Trying 128.2.232.95...
       Connected to foobar.andrew.cmu.edu.
       Escape character is '^]'.
       * OK foobar.andrew.cmu.edu Cyrus IMAP4 v2.0.0 server ready
    

    Любое сообщение, которое не начинается с "* OK" говорит о наличии какой-либо проблемы. Для закрытия соединения напечатайте ". logout".

    Естественно, номер версии должен соответствовать номеру версии сервера, который Вы установили.

  2. Используйте "imtest" для проверки входа с использованием пароля в открытом виде(plain):
       /usr/local/bin/imtest -m login foobar
    
    

    Если Вы хотите сделать это под другим именем пользователя, то:

       /usr/local/bin/imtest -m login -a USER foobar
    
    
    Если Ваш сервер запущен, Вы увидите следующие сообщение:
       % /usr/local/bin/imtest -m login foobar
       S: * OK mail1.andrew.cmu.edu Cyrus IMAP4 v2.0.0 server ready
       C: C01 CAPABILITY
       S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS 
       X-NON-HIERARCHICAL-RENAME NO_ATOMIC_RENAME AUTH=GSSAPI AUTH=ANONYMOUS 
       AUTH=KERBEROS_V4 UNSELECT
       S: C01 OK Completed
       Password: 
       + go ahead
       L01 OK User logged in
       Authenticated.
       Security strength factor: 0
    

    Любое сообщение, которое не начинается с "L01 OK " говорит о проблеме. Если проверка неудачна, сообщения об ошибках будут записанны через syslog в серверные логи. Для закрытия соединения наберите ". logout".

  3. Теперь нужно протестировать различные аутентификационные механизмы, которые Вы установили на сервер. Поддерживаемые аутентификационные механизмы перечислены в строке CAPABILITY:
      * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS 
      X-NON-HIERARCHICAL-RENAME NO_ATOMIC_RENAME AUTH=ANONYMOUS
      AUTH=KERBEROS_V4 AUTH=DIGEST-MD5 AUTH=CRAM-MD5 UNSELECT
      . OK Completed
    
    Каждому названию механизма предшествует 'AUTH= '. В этом примере доступны механизмы ANONYMOUS, KERBEROS_V4, DIGEST-MD5 и CRAM-MD5. Если там нет механизма, который Вы собирались использовать, то проверьте логи libsasl. Вообще, если механизм не пресутствует в списке, то это значит, что его не удалось инициализировать. (Например, если у сервера нет доступа к файлу srvtab, механизм KERBEROS_V4 не будет загружен.)

    Plaintext login - особый сулчай: SASL-механизм PLAIN  объявляется только при зашифрованном подключении. Однако, plaintext logins доступны (пока Вы не отключите plaintext) при использовании  -m login(как выше).

    Для закрытия соединения наберите ". logout".

    Если Вы удовлетворены списком механизмов, ножно попытаться залогиниться с использованием каждого из этих маханизмов. Запустите imtest указывая механизм для проверки.

       /usr/local/bin/imtest -m KERBEROS_V4 foobar
       C: C01 CAPABILITY
       S: * OK foobar.andrew.cmu.edu Cyrus IMAP4 v2.0.0 server ready
       S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE
       UIDPLUS X-NON-HIERARCHICAL-RENAME NO_ATOMIC_RENAME AUTH=ANONYMOUS
       AUTH=GSSAPI AUTH=KERBEROS_V4 UNSELECT
       S: C01 OK Completed
       C: A01 AUTHENTICATE KERBEROS_V4
       S: + wYcDAA==
       C: BAYBQU5EUkVXLkNNVS5FRFUAOCAm7F/Y+HabCzJ
          /UMtVcvWRjTohuq/USaCV6gYdkAU5DOcADAq
       S: + 0aAsUGQZhgQ=
       C: ADMe/cVivAYYzy1yd4Vojg==
       S: A01 OK Success (privacy protection)
       Authenticated.
       Security strength factor: 56
    

    Сообщения, которые не начинаются с "A01 OK" говорят о наличии проблемы. Если тест не пройден, сообщения с ошибками подут записанны через  syslog в серверные логи. Для закрытия соединения наберите ". logout".

    Для полного описания всех механизмов обратитесь к документации libsasl. Она может поддеривать "security layers" (защита секретности и целостности соединения). По умолчанию, imtest использует самый сильный механизм из доступных; используйте "-l " для выбора альтернативы.



Апгрейд предыдущих версий

Upgrading from 2.1.13 or earlier

Upgrading from 2.1.12 or earlier

Upgrading from 2.1.3 or earlier

Upgrading from 2.1.2 or earlier

Upgrading from 2.1.1 or 2.1.0

nothing known

Upgrading from 2.0.16 or earlier

Upgrading from 2.0.6, 2.0.7, 2.0.8, or 2.0.9 or earlier

Upgrading from a previous 2.0 version to 2.0.6

Warning: You do not need to follow these instructions if you're upgrading from version 1.6.

Upgrading from 1.6.22 or 1.6.24

Warning: Cyrus imapd 2.0 will automatically convert on-disk file formats as the server is used. It is not possible to run 1.6 after 2.0 has been used on a mail spool without reconstructing every mailbox.

Upgrading from 1.6.13

Upgrading from 1.5



Установка и настройка Cyrus IMAP Server

Internet Message Access Protocol (IMAP) является стандартным протоколом Internet для доступа к сообщениям (почта, новости и т. д.). IMAP хранит сообщения и обеспечивет к ним доступ.

Файл  doc/questions.html содержит список вопросов которых анм не задают, но на которые мы хотели бы ответить; doc/faq.html содержит некоторые ответы, над которыми нам пришлось задуматься.

Пожалуйста, обращайтесь к   Sending Feedback если вы хотите узнать о багах, особенностях или патчах.

Для уточнения конкретных изменений смотрите файл  doc/changes в дистрибутиве.

Содержание

Другие материалы

Вот некоторое ПО, которое может работать вместе с Cyrus'ом. Этот софт либо поддерживается либо не поддерживается CMU, это Вы можете уточнить у распространителей(?).


last modified: $Date: 2002/11/14 16:23:04 $ 
Назад

info-cyrus mailing list

We run a mailing list for users of Project Cyrus software. The info-cyrus@andrew.cmu.edu mailing list exists for the discussion of this server and other Cyrus software. Please do NOT send subscription requests to the list.

To subscribe: Send mail to majordomo@lists.andrew.cmu.edu to subscribe with the body of 'subscribe info-cyrus' (or just click the link above and that should just work).

An archive is availible via anonymous IMAP at imap://cyrus.andrew.cmu.edu/archive.info-cyrus.

A web archive is also available at http://asg.web.cmu.edu/archive/mailbox.php3?mailbox=archive.info-cyrus

If you are not subscribed to the list (or you are sending the message from a different address than the one which you are subscribed under), your message is directed to a human for approval. Unfortunately, the human does not always promptly process the message.

There is also a developers list available at cyrus-devel@lists.andrew.cmu.edu. with similar subscription methods and archive location

Detailed contact information can be found at http://asg.web.cmu.edu/cyrus/contacts.html


last modified: $Date: 2003/02/24 23:56:23 $
Return

Cyrus IMAP Server Офицальная информация

IMAP (Internet Message Access Protocol) является стандартным протоколом Internet для доступа к сообщениям (почта, доски объявлений, новости и т.д.). Сервер Cyrus IMAP отличается от других IMAP-серверов тем, что он может быть использован в системах, где обычным пользователям не разрешен вход(login). Почтовая база данных размещена в файловой системе и доступна только из Cyrus IMAP. Пользователи могут получать сообщения по IMAP, POP3, или KPOP-протоколу.

Почтовая база данных разработана с учетом эффективности, масштабируемости и эффективности администрирования. Возможно несколько конкурирующих соединений в режиме чтения/записи к одному и тому же почтовому ящику. Сервер поддерживает списки контроля доступа( ACL )  и квотирование.

Особенности

Cyrus поддерживает протокол IMAP4rev1 описанный в RFC 3501. IMAP4rev1 был одобрен как рекомендованный стандарт.

Кодировки, поддерживаемые для поиска: us-ascii, iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8, iso-8859-9, koi8-r, iso-2022-jp, iso-2022-kr, gb2312, big5, iso-8859-15, windows-1252, windows-1256. Очень может быть, что в данной реализации таблицы символов содержат ошибки!

Сервер поддерживает любые аутентификационные механизмы, доступные из библиотеки SASL. На данный момент это: KERBEROS_V4, GSSAPI, CRAM-MD5, DIGEST-MD5, OTP, PLAIN, и STARTTLS.

Сервер поддерживает imaps/pop3s (IMAP/POP3 + SSL).

Сервер попытается сделать одну копию сообщения в БД адресованного нескольким пользователям.

На данный момент поддерживаются следующие особенности IMAP: IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS .

Есть поддержка SIEVE , для фильтрации сообщений на стороне сервера.

Upgrade Caveats

Эта секция зарезервирована.

Краткий обзор установки

Этот пакет распространяется только в виде исходного текста. Это означает, что Вы должны скомпилировать и сконфигурировать все сами. Инструкции по установке есть в   install.html . Пожалуйста прочтите этот документ.

Более детальный обзор сервера доступен в  overview.html .

Этот сервер нормально встает на Unix -системы. Мы запускаем его на SPARC Solaris 2.7. Пожалуйста посмотрите os.html для решения проблем, связанных с операционными системами.

Примечания

Формат именен почтовых ящиков соответствует netnews--иерархическим именам разделенными символом  " . ". Ящики не имеющие "родителей" могут быть созданы только администратором. Ящики имеющие "родителей" могут быть созданы в соответствии с   ACL (Access Control List) родительского ящика.

Персональные почтовые ящики пользователей располагаются в иерархии " user ". Имена  для всех персональных ящиков для пользователя " bovik " начинаются с префикса " user . bovik . ". Ящик " user.bovik " является для пользователя " bovik " аналогом " INBOX ". Создание ящика " user . bovik " эквивалентно созданию аккаунта для пользователя " bovik "-с разрешениями " bovik " для получения почты, создания персональных почтовых ящиков и подписки на ящики. Удаление ящика " user . bovik " удаляет все ящики начинающиеся с " user . bovik . " и удаляет подписку для " bovik ".

Licensing Information

The following copyright applies to the code:
 * Copyright (c) 1994-2000 Carnegie Mellon University.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer. 
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. The name "Carnegie Mellon University" must not be used to
 *    endorse or promote products derived from this software without
 *    prior written permission. For permission or any legal
 *    details, please contact  
 *	Office of Technology Transfer
 *	Carnegie Mellon University
 *	5000 Forbes Avenue
 *	Pittsburgh, PA  15213-3890
 *	(412) 268-4387, fax: (412) 268-7395
 *	tech-transfer@andrew.cmu.edu
 *
 * 4. Redistributions of any form whatsoever must retain the following
 *    acknowledgment:
 *    "This product includes software developed by Computing Services
 *     at Carnegie Mellon University (http://www.cmu.edu/computing/)."
 *
 * CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
 * THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
 * AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE
 * FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
 * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
 * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

If you find this software useful and valuable in your work, we would welcome any support you can offer toward continuing this work. We gratefully accept contributions, whether intellectual or monetary. Intellectual contributions in the form of code or constructive collaboration can be directed via the feedback page.

If you wish to provide financial support to the Cyrus Project, send a check payable to "Carnegie Mellon University" to

      Project Cyrus
      Computing Services
      Carnegie Mellon University
      5000 Forbes Ave
      Pittsburgh, PA 15213
      USA

Заключение

Если вы хотите инсталлировать сервер, то прочтите инструкцию по установке install.html .

Более подробная информация о сервере здесь.

Пожалуйста, прочтите Sending Feedback если вы хотите оформить подписку на рассылку о багах и получать патчи.

Это майлинг-лист. Более подробно смотрите тут.

Список большинства известных проблем можно найти в bugs .html .

У O'Reilly есть книга под названием  Managing IMAP . Там дохрена всего полезного.


last modified: 2001/08/03 21:18:05
Return to the Cyrus IMAP Server Home Page

Cyrus IMAP Server Man Pages

User Commands Subroutines File Formats System Administration

Замечания связанные с особенностями операционных систем

Все

  1. Теневые пароли 
    В любой системе с теневыми паролями (включая Solaris 2.5 с Unix-аутентификацией), прочтите тщательно документацию по SASL чтобы удостовериться, что все настроенно правильно.

Solaris

  1. Современные системы Solaris имеют несколько полезных утилит в /usr/proc/bin, среди них есть  pmap. Она может быть использована для подсчета incremental cost (число не выделенных страниц) процесса imapd, это может быть полезно.

HP-UX

  1. Memory mapping support (mmap(2) ) в HP-UX не имеет правильной семантики для сервера Cyrus IMAP в 9.0 и 10.0 релизе операционной системы. Кажется, это связанно с использованием аппаратных средств. При крупномасштабной системе почты рекомендуется выбрать другую платформу. 

  2. HP-UX 9.0.4: Коментарии тестеров 
    C, который поставляется с HP-UX абсолютно не подходит для unix-пакетов. Или HP-UX ANSI C developers kit должен быть куплен отдельно от HP или GNU компилятор gcc (который может собрать себя с помощью основного HP C) должен быть собран на целевой системе.

Linux

  1. Синхронизирование обновления файловой системы. 
    Включая синхронные обновления ext2fs, все обновления становятся синхронными. Это хорошо для надежности. Плохо для производительности.

    Была большая проблема с файлом ящиков. В релизе2.0 и более поздних эта проблема решается с помощью размещения содержимого этого файла в базе данных Berkerley DB.

    Обратите внимание, что это только для ext2fs. Если Вы используете более новую файловую систему (такую как xfs, jfs или reiserfs) проблемы с синхронизацией метаданных быть не должно. Хотя мы не смотрели как работает сервер с другими файловыми системами linux. (Похоже, что разные файловые системы поддерживают немного разную симантику, и нельзя сразу сказать с какой системой все заработает, а скакой нет.)



Cyrus IMAP Server: Обзор и Концепции

Этот документ содержит обзор Cyrus IMAP server. Cyrus IMAP (Internet Message Access Protocol) Server предоставляет доступ к почте и доскам объявлений  посредствам протокола IMAP. Cyrus IMAP server является масштабируемой почтовой системой разработанной для использования на предприятиях любого масштаба с использованием основных стандартов и технологий.

Cyrus IMAP позволяет создать несвязанную почтовую систему настроенную через множество серверов (?). От других IMAP-серверов Cyrus отличает то , что он является "запечатанным" сервером, на котором пользователям не разрешено логиниться. Почтовая база данных размещена в файловой системе и доступна только из Cyrus IMAP . Пользователи могут получать сообщения по IMAP, IMAPS, POP3, POP3S, или KPOP -протоколам.

Почтовая база данных разработана с учетом эффективности, масштабируемости и эффективности администрирования. Возможно несколько конкурирующих соединений в режиме чтения/записи к одному и тому же почтовому ящику. Сервер поддерживает списки контроля доступа( ACL )  и квотирование.

Этот документ организован следующим образом:

Имена почтовых ящиков

По умолчанию, Cyrus IMAP Server для именования ящиков использует соглашение имен netnews . Именя ящиков чувствительны к регистру. Именя не могут начинаться с символа "." , и не может содержать два подряд идущих символа ".".

Не ASCII символы и метасимволы shell не допускаются.

По желанию, вы можете использовать соглашение  об иерархии UNIX.

Стандартное (Внутреннее) именование

Все персональные ящики пользователя "bovik" начинаются со строки "user.bovik.". Например, если пользователь "bovik" имеет ящик "work", то этот ящик будет иметь имя "user.bovik.work". Для пользователя "bovik ", однако, префикс "user.bovik." будет виден как "INBOX.". Т.е. "user.bovik.work" будет выглядеть как "INBOX.work". Если  ACL этого ящика разрешает другим пользователям просматривать этот ящик, то они будут видеть его как "user.bovik.work".

Почтовый ящик "user.bovik" - это нечто, где пользователь "bovik " получает новую почту и это нечто пользователь "bovik" видит, как "INBOX". В этом документе ящик "user.bovik " есть  INBOX для пользователя "bovik".

Администраторы создают и удаляют пользователей посредствам создания и уделения пользовательских  INBOX-ов. Если пользователь имеет  INBOX, значит ему разрешено подписываться на этот ящик. Только пользователи без точек в своем имени могут иметь  INBOX. (Пользователи с точками в имени смогут логиниться, но не смогут получать почту. Но если Вы используете в качестве разделителя UNIX-иерархический разделитель(как правило '/'), то любой пользователь может именть точку в имени и все будет работать.)

Когда админ удаляет пользовательский  INBOX, то все персональные почтовые ящики этого пользователя удаляются..

В контексте, где разрешены относительные имена ящиков, именование осуществляется следующим образом:

Таким образом, если Вы работаете с папкой, у которой самая верхняя родительская папка "cmu. ", имя "comp.infosystems.www" преобразуется в "comp.infosystems.www", а имя ".comp.infosystems.www" преобразуется "cmu.comp.infosystems.www".

Альтернативное именование

Cyrus IMAP Server может использовать  альтернативное именование  которое позволяет пользователям видеть их личные ящики на одном уровне с INBOX . При этом может оказаться, что несколько пользователей используют одно и тоже имя ящика (2 разных пользователя могут иметь ящик "work"), но внутренне представление всеравно остается вида:  user.name.work.

Т.е. иерархия папок сохраняется, но пользователи видят все это, как будто никакой иерархиинет и все папки всех пользователей лежат в корне сервера. -Прим. пер.

 

Access Control Lists

Доступ к каждому ящику контролируется с помощью списка контроля доступа конкретного ящика (ACL). Access Control Lists (ACL) обеспечивает мощный механизм для определения пользователей и групп пользователей, которые имеют доступ к конкретному ящику. ACL может состоять из нуля или больше записей. Каждая запись состоит из идентификатора и разрешений. Идентификатор определяет пользователя или группу пользователей к которым применяется данная запись. Разрешения состоят из одной или больше буквы или цифры, каждая буква или цифра дает определенную привелегию.

Права доступа

l
lookup - Пользователь может видеть, что ящик существует.
r
read - Пользователь может читать из ящика. Пользователь может выбрать ящик, получить данные, произвести поиск и скопироватиь данные из ящика.
s
seen - Удержание состояния пользователя. "Seen" и "Recent" флаги для пользователя устанавливаются.(?)
w
write - Пользователь может менять флаги ки ключевые слова кроме "Seen" and "Deleted" (последние управляются др. правами доступа).
i
insert -Пользователь может помещать в ящик новое сообщение.
p
post - Пользователь может посылать почту на адрес данного ящика. Это право отличается от права "i" тем, что в данном случае система доставки добавляет к письму служебную информацию.
c
create - Пользователи могут создавать подъящики от этого ящика, а так же удалять или переименовывать этот ящик.
d
delete - Пользователь может хранить флаг "Deleted" и производить вычеркивание.
a
administer - Пользователь может минять ACL ящика.
Вы можете комбинировать права. Например:
lrs
Пользователь может читать из ящика.
lrsp
Пользователь может читать из ящика и может посылать почту через систему доставки. Большинство систем доставки не обеспечивают аутентификации, так что разрешение "p" обычно имеет значение только для пользователя "anonymous".
lr
Пользователь может видеть ящик и может из него читать, но сервере не сохраняет флаги "Seen" и "Recent". Этот набор прав прежде всего необходим пользователю "anonymous IMAP."
rs
Пользователь может читать из ящика и сервер выставляет флаги "Seen" и "Recent", но пользователь ен может увидеть ящик с помощью  команд для просмотра списка ящиков. Чтобы получить доступ к ящику пользователь должен знать его имя.
lrsip
Пользователь может читать или писать в ящик через IMAP или через систему доставки ссобщений.

Идентификаторы

Идентификатор определяет пользователя или группу пользователей к которым применяется данная запись.

Существует два специальных идентификатора, "anonymous" и "anyone". Значение других идентификаторов зависит от используемого механизма авторизации(механизм .авторизации определяется параметром --with-auth во время компиляции, поумолчанию используется Kerberos).

"anonymous" и "anyone"

Не зависимо от используемого авторизационного механизма определены два идентификатора. Идентификатор "anonymous" представляет анонимного или неавторизированного пользователя. Идентификатор "anyone" представляет всех пользователей, включая анонимного пользователя.

Kerberos против Unix Authorization

Cyrus IMAP Server поставляется с тремя аутентификационными механизмами: один совместим с Unix-авторизацией("/etc/passwd"), один для использования с Kerberos и один для использования с Kerberos и группами AFS.

Помните авторизация это не аутентификация. Аутентификация это процесс определяющий кто Вы. Авторизация это прцесс определяющий Ваши права. Аутентификация обсуждается в разделе  Login Authentication . Если хотите узнать больше о разнице между авторизацией и аутентификацией - читайте  FAQ.

В аворизационном механизме Unix идентификаторы являются или действительными пользователями или группой, которая описанна в файле "/etc/group".

Так же можно использовать группы Unix аутентифицированные через НЕ-/etc/passwd механизм. Помните, использование групп, не ассоциированных с пользователями в /etc/passwd, не рекомендуется. 

При использование авторизационного механизма Kerberos, идентификаторы имеют следующий вид:

    
principal.instance@realm

Если ".instance " опущен, то поумолчанию принимается как пустая строка. Если "@realm " опущен, то поумолчанию принимается как локальная область.

" Principal ", " instance " или " realm " могут быть заменены на "* ".

Все из вышесказанного не относиться к анонимному пользователю. 

Файл "/etc/krb.equiv" содержит соответствия между пользователями Kerberos. Файл содержит ноль или более строк, каждая из которых состоит из двух полей. Идентификатор в первом поле строки канонизируется в идентификатор во втором поле. Например, следующая срока в файле "/etc/krb.equiv ":

    bovik@REMOTE.COM bovik
обозначает, что "bovik@REMOTE.COM" будет восприниматься как локальный идентификатор "bovik".

Отрицательные права.

Любой из вышеописанных идентификаторов может быть с символом "- ". В этом случае связанные права этого идентификатора будут удалены.  "отрицательные права".

Определение прав пользователей

Определяяя набора прав назначенных пользователю, сервер сначала подсчитывает все права пользователя и группы, которой он принадлежит. Затем сервер подсчитывает и удаляет все отрицательные права права пользователя и его группы.

Например возмем ACL:

   anyone       lrsp
   fred         lwi
   -anonymous   s
Пользователю "fred" будут назначены права "lrswip " и анонимному пользователю права "lrp".

Неявные права администраторов для почтовых ящиков

Независимо от ACL почтовых ящиков, пользователи перечисленные в опции "admins" в файле "/etc/imapd.conf " имеют права "l" и "a" на все почтовые ящики. Пользователи также имеют неявные права "l" и "a " на свои INBOX'ы и все свои персональные ящики.

Начальный ACL для новых ящиков

Когда создается новый ящик, его ACL копируется из ACL самого близкого родительского ящика. Когда создается пользователь, ACL его  INBOX содержит все права для этого пользователя . Когда создается не пользовательский почтовый ящик не имеющий родителей, его ACL устанавливается равный опции "defaultacl" в "/etc/imapd.conf"

Заметьте, что некоторые права устанавливаются неявно, например 'anonymous' всегда имеет право 'p' на пользовательские INBOX'ы, а пользователи всегда имеют права на ящики в пределах иерархии своих INBOX'ов.

Login Authentication

В этом разделе обсуждаются различные типы методов аутентификации (способы залогиниться), которые могут быть использованы в Cyrus IMAP.

Для аутентификации Cyrus IMAP Server использует библиотеку Cyrus SASL. В этом разделе написанно, как настроить SASL для использования совместно с Cyrus imapd. Пожалуйста изучите Cyrus SASL System Administrator's Guide для более точной информации.

Anonymous Logins

Независимо от механизма SASL, используемого для индивидуальных подключений, сервер может поддерживать анонимный вход. Если опция "allowanonymouslogin " в "/etc/imapd.conf" присутствует, то сервер разрешит логиниться с открытым текстом(plaintext) для пользователя "anonymous", для которого может быть указан любой пароль. Также, сервере будет разрешать любые механизмы SASL которые позволяют осуществить анонимный вход.

Plaintext Authentication

Библиотека SASL может осуществлять верификацию plaintext-паролем несколькими путями. Plaintext-пароли передаются либо командой IMAP LOGIN, либо механизмом SASL PLAIN  (ниже уровня TLS).

Метод верификации с помощью plaintext-паролей всегда осуществляется через библиотеку SASL, даже в случае использования внутренней команды LOGIN. Это позволяет только библиотеке SASL быть источником аутентификационной информации. Почитайте про опцию sasl_pwcheck_method  в документации на SASL, чтобы понять, как настроить верификацию plaintext-паролем в вашей системе.

Для отключения аутентификации по plaitext-паролям Вы можете установить 'a llowplaintext:no' в imapd.conf. При этом PLAIN под TLS все еще будет работать, но команда IMAP LOGIN работать не будет.

Kerberos Logins

Механизм SASL Kerberos поддерживает механизм аутентификации KERBEROS_V4 . Механизм требует, чтобы файл  srvtab существовал там, куда указывает конфигурационная опция "srvtab ". Файл srvtab должен быть доступен для чтения Cyrus'у и должен содержать служебный ключ "imap.<host> @<realm> ", где <host>   - это первый компонент имени хоста сервера, а <realm>   - это область сервера Kerberos.

Сервер будет разрешать имена пользователей идентифицируя их в локальной области и в областях перечисленных в опции "loginrealms " в "/etc/imapd.conf".

Файл "/etc/krb.equiv" содержит соответствия между пользователями Kerberos. Вайл содержит ноль или более строк, каждая из которых состоит из двух полей. Идентификатор в первом поле может быть залогинен, как будто это идентификатор из второго поля.

Если конфигурационная опция"loginuseacl " включена, то любому идентификатору Kerberos, у которого есть право "a " на пользовательский INBOX, будет разрешено логиниться как будто это пользователь этого ящика.

Shared Secrets Logins

Некоторые механизмы требуют чтобы пользоваетли и сервер имели разделяемый секрет который может быть использован для проверки пароля без передачи последнего открытым текстом по сети. Для таких механизмов (например CRAM-MD5 и DIGEST-MD5), Вы должны обеспечить источник паролей, такой как sasldb (более подробно все это описано в документации на Cyrus SASL)

Квоты

Квоты приминяются системными администраторами для ограничения использования ресурсов иерархией почтовых ящиков на сервере.

Поддержка квот на хранилище

Cyrus IMAP Server поддерживает квотирование на хранилище, которое определяется как число байт в сообщении RFC-822, in kilobytes. Каждая копия сообщения подсчитывается независимо, даже если сервер использует жеский ссылки на копии для уменьшения используемого дискового пространства.Дополнительное дисковое пространство, используемое индексными файлами и файлами кеша, не учитывается.

Квота крня

Квота примененная к корню, может быть применена на любом уровне иерархии. Квота корня не может быть квотой на ящик.

Квота корня применяется к сумме объема использованного ящиком и всеми его подъящиками у которых нет своей квоты. Это означает, что у ящика может быть только одна корневая квота. 

Например, если ящики 

   user.bovik
   user.bovik.list.imap
   user.bovik.list.info-cyrus
   user.bovik.saved
   user.bovik.todo

существуют, и есть квоты на ящики

   user.bovik 
   user.bovik.list
   user.bovik.saved,
то корневая квота "user.bovik" применяется к ящикам "user.bovik" и "user.bovik.todo"; корневая квота "user.bovik.list" применяется к ящикам "user.bovik.list.imap" и "user.bovik.list.info-cyrus"; коренвая квота "user.bovik.saved " применяется к ящику "user.bovik.saved".

Корневая квота создается автоматически при выполнении команды "setquota". Корневые квоты не могут быть удалены через протокол, читайте  Удаление корневых квот чтобы узнать, как удалить их.

Mail Delivery Behavior

Обычно, когда сообщение должно быть помещено в ящик, корневая квота должна иметь достаточно неиспользованного места, иначе помещение сообщения в ящик будет заблокированно из-за превышения квоты.

Доставка почты - особый случай. При доставки сообщения в ящик, корневая квота этого ящика не должна быть превышена. Если квота не превышена, то только одно сообщение может быть доставлено независимо от его размера. Это вызывает превышение квоты данным ящиком, поставив в известность пользователя и дав ему возможность исправить ситуацию(?). Еслиб в таком случае доставка не разрешалась, то пользователь не узнал бы, что была почта которую нельзя доставить.

-- Прим. пер.

Т.е. наверное хотели сказать, что при доставки сообщения проверяется не превышена ли квота в данный момент, без учета размера поступающего сообщения. После доставки ящик проверяется еще раз(с учетом нового сообщения) на превышение, и если квота превышена, то пользователю высылается уведомление.

---

Если квота превышена, то доставка будет неудачной с временной ошибкой. Это заставит систему доставки в течении нескольких дней пытаться заново доставить сообщение, (давая пользователю возможность исправить проблему) а затем вернуть его отправителю.

Предупреждение при превышении квоты для пользователя имеющего право  "d "

Когда пользователь выбирает ящик, корневая квота которого превышена или близка к этому, и пользователь имеет право "d " на этот ящик, сервер выдаст пользователю предупреждение о превышении квоты. Порог после которого выдается предупреждение устанавливаетя конфигурационной опцией "quotawarn ".

Сервер выдает такое предупреждение только если пользователь имеет право "d" на ящик, т.к. только пользователи с правом "d" могут решить проблему превышения квоты в конкретном ящике.

Квоты и Разделы

Корневые квоты независимы от   разделов. Одна корневая квота может быть применена к ящикам находящимся в разных разделах.

Уведомление о новых сообщениях

Cyrus IMAP server содержит демона уведомлений, который поддерживает множественные уведомления о новой почте. Уведомления могут быть настроенны для отправки посредствам нормальной оставки (класс"MAIL" ) и/или как запрос к скрипту  Sieve (класс"SIEVE" ).

По умолчанию оба типа отключены. Уведомления включаются спомощью использования одной из следующих опций(могут быть использованны одновременно обе):

Разделы

Разделы ползволяют администраторам хранить почтовые ящики в разных частях файловой системы Unix. Это сделано для того, чтобы можно было распределить всю иерархию почтовых ящиков по нескольким дискам.

Определение разделов с помощью "create"

Когда администратор создает новых ящик, имя раздела для этого ящика может быть задано вторым аргументом команды "create ". Не-администраторам не разрешается определять разделы для ящиков. Если раздел не определен, то ящик наследует раздел от самого близкостоящего к нему по иерархии родителя. Если ящик не имеет родителей, то раздел для него задается конфигурационной опцией "defaultpartition ".

Дополнительный второй аргумент к команде "create " могут использовать только предопределенные в настройках администраторы, например такие как  cyradm.

Изменение раздела с помощью "rename"

Администратор может изменять раздел ящика при помощи команды "rename" с дополнительным третьим аргументом. Когда указан третий аргумент, первый и второй аргументы могут быть одинаковыми - в этом случае ящик не переименовывается, а только меняется его раздел. Если третий аргумент не задан, а первый аргумент не "INBOX ", то раздел ящика не изменится. Если третий аргумент не задан, а первый аргумент равен "INBOX ", то раздел будет такой же, как после команды "create" для этого ящика.

Новости

Раздел содержит обзор концепций для реализации экспорта новостных групп(телеконф.) черех IMAP-сервер.

Раздел "news"

Раздел с именем "news" зарезервирован для netnews(конференции) и неможет быть использован для других целей.

Netnews

IMAP-сервер может экспортировать конференции как почтовые ящики IMAP. Это делается с помощью создания раздела с именем "news" который указывает на буферную директорию новостей (news spool) в которой создается вспомогательная база данных для IMAP-сервера. В данном сервере есть необходимый софт для интеграции с INN-сервером(Internet Net News). Следующая информация предпологает наличие практических знаний по работе INN-сервера.

collectnews

Программа "collectnews" получает на входе список путей статей(тем) относительно spool-директории. Таким образом  все сообщения помещаются во вспомогательную БД. Если collectnews сталкивается с конференцией у которой нет передающего ящика IMAP перечисленного в файле почтовых ящиков (описанно ниже), то такой ящик создается.

 

Т.е. на каждую конфу создается отдельный ящик, все(или не все) пользователи имеют доступ к этим ящикам. -Прим. пер.

 

Программа "collectnews" обычно запускается cron'ом от имени cyrus-пользователя. Т. к.  collectnews должна будет осуществлять запись во вспомогательную БД расположенную spool-директории,  cyrus-пользователь должен входить в новостную группу, а новостная группа должна иметь право на запись в spool-директорию.

rmnews

Программа "rmnews" получает на входе список путей статей(тем) относительно spool-директории. Она удаляет любые ссылки(т.е. все экземпляры сообщений -Прим. пер.) сообщений во вспомогательной базе и отсоединяет файлы статей. Программа "rmnews" используется для удаления устаревших и закрытых статей(тем).

У "Rmnews" такой же формат вводимых данных как и у программы "fastrm". Обычно "Rmnews " запускают для  очистки после  устаривания  вызыва news.daily с аргументом "delayrm " и с  RMPROC в expirerm измененным с "fastrm" до "rmnews".

Rmnews также можно запускать из  cron'а от имени  cyrus-пользователя для remove завуршенных и отмененных статей(тем).

Поскольку деятельность "rmnews" связана с изменениями во вспомогательной базе, то она должна быть установленна(запущена -Прим. пер.) с uid таким же как у user-пользователя и gid таким же, как у новостной группы.

syncnews

Программа "syncnews" получает в качестве аргумента имя файла активных новостей. Она сравнивает список новостных ящиков IMAP с файлом активных новостей. Новостные ящики не перечисленные в файле активных новостей удаляются. Для конференций перечисленных в этм файле, но не имеющих ящиков IMAP создаются новые ящики.

Конференция должна иметь статус  ``y'', ``m'', или ``n'' указанный в файле активных новостей. Программа "syncnews " должна запускаться от имени cyrus-пользователя через cron хотябы раз в день.

Сервер POP3

В Cyrus IMAP Server имеется POP3-сервер. Из-за ограничений в протоколе POP3, сервер может предоставить доступ только к пользовательскому  INBOX'у и в одну единицу времени POP3-сервер может работать только с одним пользователем. Пока POP3-сервером открыт пользовательский INBOX, любые другие конкурирующие IMAP-сессии будут неудачными.

Короче говоря - конкурирующие подключения(и к POP3 и к IMAP) в случае использования POP3-сервера не поддерживаются.

Когда используется вход с Kerberos-аутентификацией, пользователи POP3-сервера будут иметь идентификаторы "pop.host@realm " вместо imap.host@realm , где " host " первый компонент имени хоста сервера, а " realm " облать Kerberos. Когда POP3-сервер запускается с ключем "-k", он будет экспортировать протокол MIT KPOP вместо обычного POP3.

The syslog facility

Cyrus IMAP Server пишет сообщения в логи через средство(фасилити, facility) "local6 " syslog'а. Используются следующие уровни важности:

Восстановление Mail Directory

Этот раздел описывает различные базы данных используемые сервером Cyrus IMAP и что можно сделать при несовместимости этих баз.

Реконструирование директорий ящиков

Самая большая база - это директории почтовых ящиков. Каждая директоря (у каждого ящика своя директория -Прим. пер.) соедржит:
файлы сообщений
Это один файл на сообщение, содержащий сообщение в  формате RFC 822. Строки в сообщении разделены символами CRLF, а не LF. Имя файла каждого сообщения является UID сообщения следующим за точкой (.).

В новостных конференциях, соответствуют формату и соглашеню о именовании которое определяется новостным софтом .

cyrus.header
Файл содкржит системные коды и информацию нефиксированного размера о ящике.

cyrus.index
Файл содержит информацию фиксированного размера о ящике и каждом сообщении в ящике.

cyrus.cache
Содержит информацию нефиксированного размера о каждом сообщении в ящике.

cyrus.seen
Этот файл содержит информацию нефиксированного размера о состоянии каждого пользователя,  который имеет право "s" на этот ящик.
Программа "reconstruct" может быть использованна для восстановления поврежденных директорий ящиков. Если "reconstruct" сможет найти существующий заголовок и индексные файлы, то она попытается сохранить любые данные которые неудается получить непосредственно из файлов сообещний. Режим "reconstruct" будет пытаться сохранить имена флагов, состояние флагов и внутреннюю дату. Всю остальную информацию "reconstruct " получает из файлов сообщений.

Администратор может восстановить информацию в резельтате повреждения диска восстановив сообщения из бэкапа и запустив reconstruct для генерирования директорий из других файлов.

Программа "reconstruct" не регулирует квотирование описанное в любых файлах корневых квот. После запуска reconstruct, будет нелишним запустить "quota -f " (описанно ниже) для исправления файлов корневых квот.

Реконструирование файла щяиков

ЗАМЕЧАНИЕ: В ДАННЫЙ МОМЕНТ НЕПОДДЕРЖИВАЕТСЯ 

Файл ящиков в конфигурационной директории - самый критический во всей системе Cyrus IMAP. Он содержит упорядоченный список всех ящиков в системе, вместе с ящиками содержится корневыя квота и ACL. Для реконструирования поврежденного файла ящиков, необходимо запустить команду "reconstruct -m " .Программа "reconstruct ", когда получит ключ "-m", очистит и откорректирует всю информацию, которую сможет найти в файле ящиков. Она просканирует все разделы перечисленные в файле imapd.conf file чтобы добавить их в файл ящиков все расположенные там директории ящиков.

Файл  cyrus.header в каждой директории каждого ящика содержит резервную копию ACL этого ящика, эта копия используется как бэкап при перестроении файла ящиков.

Реконструирование корневой квоты

Поддиректория "quota" конфигурационной директории (определяется конфигурационной опцией "configdirectory") содержит один файл на одну корневую квоту, с именем файла таким же, как имя корневой квоты. Эти файлы содержат информацию об использовании квоты и лимитах на каждую корневую квоту.

Программа "quota " с ключем "-f", пересчитает корневые квоты для всех ящиков и использование квоты для каждой корневой квоты.

Удаление корневых квот

Для удаления коренвых квот нужно файл корневых квот. Затем запустить "quota -f " чтобы создать файл корневых квот заново.

Подписки

Поддиректория "user" конфигурационной директории содержит пользовательские подписки. Это один файл на пользователя, в качестве имени файла идентификатор пользователя + ".sub ". Каждый файл содержит упорядоченный список подписанных ящиков.

Программы для восстановления поврежденного файла подписок нет. Файл подпискок можно восстановить из бэкапа.

Конфигурационная директория

Большая часть объектов конфигурационной директории описана в разделе восстановления Mail Directory. Этот раздел документирует две другие поддиректории расположенные в конфигурационной директории.

Директория"log "

Поддиректория "log " в конфигурационной директории позволяет администраторам осуществлять протоколирование пользовательских сессий.

Если в директории "log" существует поддиректория именем таким же, как имя какого-либо пользователя, то IMAP и POP3-сервера будут вести логи этого пользователя. Логи будут расположены в файлах с именами равными идентификатору процесса сервера и будут начинаться с первой команды следующей после аутентификации.

Директория "proc"

Поддиректория "proc" в конфигурационной директории содержит по одному файлу на каждый процесс сервера. Имена файлов - это представленные в ASCII идентификаторы процессов сервера, а содержимо состоит из двух разделенных табом(tab) полей: Файл может содержать произвольные символы после символа новой строки.

Поддиректория "proc " обычно очищается при перезагрузки сервера.

Доставка сообщений

MTA, такие как Sendmail, Postfix, или Exim взаимодействуют с Cyrus'ом через LMTP (Local Mail Transport Protocol) с помощью демона LMTP. Это может быть реализовано либо напрямую от MTA (это наиболее предпочтительно из соображений о скорости передачи) или через LMTP-клиента.

Local Mail Transfer Protocol

LMTP, Local Mail Transfer Protocol, является версией(вариантом) SMTP разработанной для доставки сообщений до конечной точки хранения. LMTP позволяет MTAs доставлять "local"-почту через сеть. Такой механизм легко оптимизируется, т. к. IMAP-сервер не должен обслуживать очередь сообщений или быть совместимым с MTA. (короче говоря - это просто протокол(типа SMTP) для передачи сообщений от MTA к почтовику, в нашем случае к Cyrus'у - Прим. пер.)

Сервер Cyrus работает по LMTP через демон lmtpd. LMTP можно пользоваться либо через сеть посредствам TCP, либо либо локально через сокеты UNIX(доменные гнезда). Между этими двумя альтернативами есть разница в безопастности; читайте об этом ниже.

Для конечной доставки по LMTP через TCP-сокет необходимо оспользовать LMTP AUTH. Это можно осуществить используя SASL аутентификации пользователя доставки. Если Ваш почтовый сервер осуществляет доставку через LMTP AUTH (т. е., используя механизм SASL),  Вам нужно будет сделать так, чтобы Ваш аутентификационный идентификатор был LMTP-админом (указан в опции  admins в imapd.conf или в опции  lmtp_admins ).

Альтернативный способ заключается в доставке по LMTP через сокет unix от имени пользователя с правами адинистратора(?) (контроль доступа осуществляется на основании прав доступа к этому сокету).

Заметьте, если у пользователя есть скрипт sieve, то этот скрипт запускается с правами *этогоt* пользователя и права отправляющего(post user) пользователя игнорируются с целью определения  результата sieve-скрипта.

Хранение в единственном экземпляре

Если осуществляется доставка нескольким получателям (возможно только если MTA использует  LMTP через lmtpd ), сервер попытается сохранить несколько копий сообщениий, если это возможно. Будет создана одна копия на раздел, и созданы жестские связи(не символьные) на сообщение для всех получателей.

Хранение в единственном экземпляре может быть выключено с помощью использования флага "singleinstancestore" в конфигурационном файле.

Подавление двойной доставки

Сообщение считается продублированным если две копии собщения имеют одинаковый идентификатор (message-id) и одного и того же получателя. Cyrus использует для хранения информации о дубликатах специальную базу данных, информация в базе храниться поумолчанию 3 дня. (Т.е. все записи старше трех дней вытераются из базы - Прим. пер.)

Подавление двойной доставки можно отключить с помощью флага "duplicatesuppression" в конфигурационном файле.

Sieve, Mail Filtering Language(язык фильтрации сообщений)

Sieve является языком фильтрации сообщений который может фильтровать сообщения в указанных почтовых ящиках IMAP во время доставки по lmtp. Для подробностей жми  сюда.

Cyrus Murder, IMAP Aggregator

Теперь Cyrus поддерживает распределение ящиков по нескольким IMAP-серверам, таким образом достигается горизонтальная масштабируемость. За полее детальной информацией по настройке такой сисьемы жмите  сюда.


Вернуться  на Cyrus IMAP Server Home Page



Sieve: A mail filtering language

Sieve is a Internet standards-track protocol for filtering messages on delivery. The Cyrus Sieve implementation supports filing messages into specific folders, forwarding messages, rejecting messages, and the standard vacation function. It can reply to messages based on headers or envelope information.

Cyrus Sieve

Some simple sample Sieve scripts


Cyrus IMAP Server Protocol Specifications


IMAP

RFC 3501 Internet Message Access Protocol - version 4rev1
RFC 1730 Internet Message Access Protocol - version 4
RFC 1731 IMAP4 Authentication Mechanisms
RFC 2086 IMAP4 ACL extension
RFC 2087 IMAP4 QUOTA extension
RFC 2088 IMAP4 non-synchronizing literals
RFC 2177 IMAP4 IDLE command
RFC 2192 IMAP URL Scheme
RFC 2193 IMAP4 Mailbox Referrals
RFC 2342 IMAP4 Namespace
RFC 2359 IMAP4 UIDPLUS extension
RFC 3502 IMAP MULTIAPPEND extension
RFC 2595 Using TLS with IMAP, POP3 and ACAP
RFC 2971 IMAP4 ID extension
RFC 3348 IMAP4 Child Mailbox Extension
draft-melnikov-imap-unselect IMAP UNSELECT command
draft-ietf-imapext-sort IMAP SORT and THREAD Extension
draft-ietf-imapext-list-extensions IMAP4 LIST Command Extensions
draft-daboo-imap-annotatemore IMAP ANNOTATEMORE Extension

POP

RFC 1939 Post Office Protocol - Version 3 (POP3)
RFC 1734 POP3 AUTHentication command
RFC 2449 POP3 Extension Mechanism
RFC 2595 Using TLS with IMAP, POP3 and ACAP
RFC 3206 The SYS and AUTH POP Response Codes

SASL

RFC 2222 Simple Authentication and Security Layer (SASL)
being revised by draft-myers-saslrev
RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response
being revised by draft-nerenberg-sasl-crammd5
RFC 2245 Anonymous SASL Mechanism
being revised by draft-zeilenga-sasl-anon-00
RFC 2444 The One-Time-Password SASL Mechanism
RFC 2595 Using TLS with IMAP, POP3 and ACAP
RFC 2831 Using Digest Authentication as a SASL Mechanism
being revised by draft-melnikov-rfc2831bis

TLS/SSL

RFC 2246 TLS Protocol
draft-freier-ssl-version3 The SSL Protocol Version 3.0
draft-hickman-netscape-ssl The SSL Protocol

LMTP

RFC 2033 Local Mail Transfer Protocol
RFC 2821 Simple Mail Transfer Protocol (SMTP)
RFC 1869 SMTP Service Extensions
RFC 1652 SMTP Service Extension for 8bit-MIMEtransport
RFC 1870 SMTP Service Extension for Message Size Declaration
RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
RFC 3463 Enhanced Mail System Status Codes
RFC 3207 SMTP Service Extension for Secure SMTP over TLS
RFC 2554 SMTP Service Extension for Authentication
RFC 2920 SMTP Service Extension for Command Pipelining
draft-murchison-lmtp-ignorequota LMTP Service Extension for Ignoring Recipient Quotas

Sieve

RFC 3028 Sieve: A Mail Filtering Language
RFC 3431 Sieve Extension: Relational Tests
RFC 3598 Sieve Email Filtering -- Subaddress Extension
RFC 2298 Extensible Message Format for Message Disposition Notifications (MDNs)
draft-showalter-sieve-vacation Sieve -- Vacation Extension
draft-melnikov-sieve-imapflags Sieve -- IMAP flag Extension
draft-murchison-sieve-regex Sieve -- Regular Expression Extension
draft-martin-sieve-notify Sieve -- An extension for providing instant notifications
draft-martin-managesieve Protocol for Remotely Managing Sieve Scripts

Other

RFC 2822 Internet Message Format
draft-siemborski-mupdate MUPDATE Protocol (For Cyrus Murder)