The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "Настройка почты (sendmail, postfix, qmail)" / Оглавление документа

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




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру