Чужой опыт экономит время и увеличивает шансы для удачи

Копии всех отправленных

В заметке разобраны варианты использования свойства Postfix авто-BCC, и как сделать так, чтобы сохранять все отправляемые письма в своих ящиках (включая отдельный ящик для писем отправляемых от несуществующих или неучтенных пользователей), избегая при этом дублирования с MUA.

ВАЖНО! Эта страница является частью списка заметок о настройке почтовой системы (Postfix+Dovecot и пр.).
Родительская страница - обязательна к просмотру: Установка и настройка почтового сервера

Подробнее о конфигурации к которой относятся примеры в этой статье - см. ссылку выше.
Тем же - коротко об основных терминах (MTA, MDA, MUA и т.п.).

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


Это скорее конспект-шпаргалка, чем достоверный справочник. Кроме ответов здесь могут присутствовать вопросы.

Содержание

  1. Кто обычно сохраняет письмо в "Отправленные"
  2. Как можно организовать контроль всех отправленных
  3. BCC копии всех писем, отправленных из родных доменов
  4. Тестирование с использованием postmap
  5. Еще один экзотический пример
  6. Возможные проблемы
  7. Перенаправление BCC-копий в "Отправленные" с использованием Sieve
  8. Как избавиться от дубликатов писем в папке "Отправленные"
  9. Источники
Здесь описываются примеры для одного конкретного частного случая конфигурации почтовой системы.

Кто обычно сохраняет письмо в "Отправленные"

Чаще всего это делает MUA. Отправляя письмо, он выполняет две операции: отправляет письмо через SMTP + сохраняет копию в "Отправленные" (на сервере, если используется IMAP, либо только на удаленном клиенте, при использовании SMTP/POP). Если же письмо через SMTP отправляет, например сайт или спамер/хакер подключившийся посредством telnet и как-то узнавший пароль, либо заливший вредоносный скрипт на сервер, то контроль за отправленными письмами полностью теряется. Тем не менее можно организовать контроль всех отправляемых писем (включая письма от несуществующего в базе PostfixAdmin отправителя) и доставку копий всех отправленных в соответствующие ящики.

Как можно организовать контроль всех отправленных

Есть несколько вариантов решения проблемы.

  • Во-первых, с помощью Postfix можно создавать копии вообще всех писем, и направлять их в один специальный ящик. Для этого нужно прописать адрес этого ящика в конфигурационном файле Postfix - "main.cf": always_bcc = allbcc@domain.tld . Кстати, сохраняться будут даже те письма, которые так и не были отправлены/доставлены (но были помещены в очередь). Он не очень экономный, т.к. диск будет заполняться бессмысленными дубликатами.

  • Во-вторых, можно там же в main.cf Postfix использовать: sender_bcc_maps = hash:/path/to/hash , или подключать существующий файл, уже используемый для проверки пользователей через MySQL: sender_bcc_maps = mysql:/etc/postfix/virtual_mailbox_maps.cf .
    В этом случае у каждого отправленного письма будет проверяться отправитель, и если он найден в зарегистрированных, то копия письма отправится ему во "Входящие". Вариант интересный, но, как минимум, теряется контроль за письмами, отправленными от неучтенных (без ящика, зарегистрированного в базе PostfixAdmin) системных пользователей, поскольку проверка таких пользователей обычно отключена. Например, письма, сгенерированные сайтом.

  • Во-третьих, можно было бы использовать предыдущий вариант наоборот, - с помощью специального SQL-запроса создавать копии только для писем незарегистрированных отправителей (как существующих, но без ящика - системных, так и вообще несуществующих, а также "чужих"). Этот вариант можно было бы принять в расчете на то, что зарегистрированные пользователи используют только MUA с доступом по IMAP (который сохраняет копии отправленных сам).

    Но в этом случае теряется контроль за отправленными письмами учтенных (в базе PostfixAdmin) системных пользователей, если зарегистрированные пользователи все-таки будут отправлять письма из удаленных MUA без IMAP (такие письма будут оставаться неучтенными за пределами сервера).

  • В-четвертых, можно в параметре sender_bcc_maps = , использовать два SQL-запроса. Первый будет использоваться для отсылки копий писем зарегистрированных отправителей им в ящик. Второй - для отсылки копий всех писем незарегистрированных или несуществующих отправителей в родном домене, в специальный единый ящик. В таком случае все отправляемые письма будут под контролем.

Именно четвертый вариант будет подробнее рассмотрен в следующих разделах.
Также будет рассмотрено использование Sieve в Dovecot для перенаправления копий отправленных из "Входящие" в "Отправленные", а также для избежания дублирования отправленных, сохраняемых MUA через IMAP.

См. также заметку с детальным описанием настройки конкретной, рассматриваемой в этой серии заметок, конфигурации: Полный пример установки всех пакетов и настройки конфигурационных файлов.

Здесь описываются примеры для одного конкретного частного случая конфигурации почтовой системы.

BCC копии всех писем, отправленных из родных доменов

возможны, благодаря тому, что можно указать несколько значений в recipient/sender_bcc_maps. Для копий отправленных, далее будет рассмотрен sender_bcc_maps.

BCC с его помощью можно создавать для ВСЕХ отправленных писем (с родными доменами), - в т.ч. и писем незарегистрированных пользователей, а также писем, отправленных из разных источников (но с использованием родного MTA).

Параметр sender_bcc_maps позволяет указать несколько значений, перечисленных через запятую. Эксперименты показали следующее: когда обрабатывается sender_bcc_maps с несколькими значениями, то сначала выполняется запрос указанный первым. Кроме того, если запрос вернул какое-то значение, то перехода к следующему - не происходит. Если же запрос не вернул строк - происходит переход к следующему запросу. Если ни один запрос не вернул строк, то отправка авто-BCC так и не состоится.

КСТАТИ! В маппинге алиасов Postfix ведет себя по-другому. Там, если первый запрос вернул значение отличное от запрашиваемого, - будет обработан следующий запрос.

Итак, задачу полного контроля над отправленными письмами можно решить двумя запросами:

  1. Первым запросом возвращать адрес отправителя только в том случае если он найден в таблице mailbox SQL-базы PostfixAdmin.
  2. Вторым запросом возвращать адрес специального единого ящика (например: "unknownsender@domain.tld") для неизвестных отправителей, но только в том случае, если доменная часть адреса отправителя найдена в таблице domain SQL-базы PostfixAdmin. И не возвращать ничего если отправитель "чужой".

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

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

/etc/postfix/main.cf :

...
sender_bcc_maps = mysql:/etc/postfix/mysql_bcc_mailbox_maps.cf,mysql:/etc/postfix/mysql_bcc_domain_maps.cf
...

/etc/postfix/mysql_bcc_mailbox_maps.cf :

user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_MySQL_

password = _ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_MySQL_

hosts = 127.0.0.1

dbname = _ИМЯ_БАЗЫ_

query = SELECT username FROM mailbox WHERE username='%s' AND active = '1'

/etc/postfix/mysql_bcc_domain_maps.cf :

user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_MySQL_
password = _ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_MySQL_
hosts = 127.0.0.1
dbname = _ИМЯ_БАЗЫ_
query = SELECT 'unknownsender@domain.tld' FROM domain WHERE domain='%d' AND active = '1'

Запрос /etc/postfix/mysql_bcc_mailbox_maps.cf по-видимому совпадает с запросом пользователя для параметра virtual_mailbox_maps = , т.е. может использоваться он-же.

Итак, имеем здесь для всех известных отправителей родных доменов - авто-BCC в их ящик, а также авто-BCC для всех неизвестных отправителей родных доменов - в специальный единый ящик. При этом отправители "чужих" доменов (входящая извне почта) - игнорируются.

Будут сохранены не только письма, отправленные не зарегистрированными в PostfixAdmin системными пользователями, но и письма активированных зарегистрированных пользователей, отправленные удаленными MUA (через родной MTA), или отправленные другими способами (например сгенерированные сайтом.)

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

Тестирование с использованием postmap

Предположим, что:
"user@domain.tld" - зарегистрированный активный ящик,
"unknownsender@domain.tld" - еще один зарегистрированный активный ящик,
"nnn@domain.tld" - незарегистрированный или неактивный ящик,
"domain.tld" - родной домен,
"user@anotherdomain.tld" - чужой ящик чужого домена.

Используем примеры из предыдущего раздела для проверки SQL-запросов через консоль (показан ввод и вывод).

  • Зарегистрированный ящик в родном домене.

    Должно вернуть имя зарегистрированного ящика в первом же запросе:

    # postmap -q user@domain.tld /etc/postfix/mysql_bcc_mailbox_maps.cf

    user@domain.tld

    Второй запрос использован не будет.
    Копия отправленного письма будет доставлена через авто-BCC в зарегистрированный ящик отправителя ("user@domain.tld").

  • Незарегистрированный ящик в родном домене.

    Нет значения для незарегистрированного ящика (родного домена) в первом запросе:

    # postmap -q nnn@domain.tld /etc/postfix/mysql_bcc_mailbox_maps.cf

    Но есть значение для незарегистрированного ящика (родного домена) во втором запросе

    # postmap -q nnn@domain.tld /etc/postfix/mysql_bcc_domain_maps.cf

    unknownsender@domain.tld

    Копия отправленного письма будет доставлена через авто-BCC в ящик "unknownsender@domain.tld".

  • Чужой ящик чужого домена.

    Нет значения для неизвестного ящика (чужого домена) в первом запросе:

    # postmap -q user@anotherdomain.tld /etc/postfix/mysql_bcc_mailbox_maps.cf

    Нет значения для неизвестного ящика (чужого домена) во втором запросе

    # postmap -q user@anotherdomain.tld /etc/postfix/mysql_bcc_domain_maps.cf

    Копия письма не будет отправлена.

Еще один экзотический пример

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

Для этого понадобится указать новый файл, описывающий запрос

/etc/postfix/main.cf :

...
sender_bcc_maps = mysql:/etc/postfix/mysql_verify_unferify_bcc_maps.cf
...

А сам файл запроса сделать, например, таким

/etc/postfix/mysql_verify_unferify_bcc_maps.cf :

user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_MySQL_
password = _ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_MySQL_
hosts = 127.0.0.1
dbname = _ИМЯ_БАЗЫ_
query = SELECT IF(COUNT(username) = 0, 'unknownsender@domain.tld', username) FROM mailbox WHERE username='%s' AND active = '1'

В этом случае будет выполняться всегда только один запрос.

Возможные проблемы

Эксперименты показали, что любые *_bcc_maps применимы только глобально (в файле "main.cf"). Любые попытки использовать их избирательно для отдельных сервисов "master.cf" ни к чему не приводят.

Стоит также помнить о том, что указанный избирательно для какого-нибудь отдельного сервиса в "master.cf", параметр "   -o receive_override_options=no_address_mappings" или глобально в "main.cf" (receive_override_options = no_address_mappings) отключает авто-BCC (избирательно или глобально). Кроме этого, он отключает алиасы, и многое другое, что может сломать весь механизм обработки почты (например автоответчики PostfixAdmin).

Перенаправление BCC-копий в "Отправленные" с использованием Sieve

С помощью Sieve, во входящих письмах проверяется отправитель и, если он совпадает с владельцем ящика, то письмо, минуя "Входящие", перенаправляется в "Отправленные".

Подробнее о Sieve, см. в соответствующей заметке - Dovecot 2 - Sieve.

Конфиг может быть примерно таким

/etc/dovecot/conf.d/90-sieve.conf :

...
  sieve_global_dir = /var/lib/dovecot/sieve/global/
...
  sieve_before = /var/lib/dovecot/sieve/global/test.sieve
...

А сам скрипт таким:

Способ 1

/var/lib/dovecot/sieve/global/test.sieve :

require ["fileinto"];
if allof (header :contains "Return-Path" "user@domain.tld")
{
        fileinto "Sent";
}

В этом способе есть одно побочное свойство - письма, отправленные самому себе будут уходить в папку "Отправленные" дважды. Первое - авто-BCC копия отправленного, второе - полученное письмо (есть еще третье отправленное - сохраненное MUA через IMAP, но об этом в следующем разделе).

Это можно изменить, если помечать авто-BCC в Postfix (см. следующий способ).

Способ 2

В этом способе письма, созданные авто-BCC, будут отправляться в "Отправленные" с распознавемым отличием в заголовках.

Итак, для того, чтобы перемещать из "Входящие" в "Отправленные" только авто-BCC письма, оставляя нетронутыми в папке "Входящие" письма самому себе, нужно будет переделать SQL-запрос Postfix, упомянутый в разделе BCC копии всех писем, отправленных из родных доменов, видоизменив адрес доставки BCC, и добавить распознавание этого изменения в Dovecot.

Изменим первый запрос в Postfix (авто-BCC для зарегистрированных пользователей)

/etc/postfix/mysql_bcc_mailbox_maps.cf :

user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_MySQL_

password = _ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_MySQL_

hosts = 127.0.0.1

dbname = _ИМЯ_БАЗЫ_

query = SELECT CONCAT('%u', '+autobcc', '@', '%d') FROM mailbox WHERE username='%s' AND active = '1'

Цветом отмечено отличие от примера из раздела выше.

Проверка:

# postmap -q user@domain.tld /etc/postfix/mysql_bcc_mailbox_maps.cf
user+autobcc@domain.tld

Подправим конфиг Postfix

/etc/postfix/main.cf :

...
recipient_delimiter = +
...

Также изменим конфиг Dovecot для Sieve

/etc/dovecot/conf.d/90-sieve.conf :

plugin {
...
  recipient_delimiter = +
...
}

И, наконец, - сам скрипт

/var/lib/dovecot/sieve/global/test.sieve :

require ["fileinto", "envelope", "subaddress"];
if envelope :detail "to" "autobcc"  {
        fileinto "Sent";
}

Здесь, в скрипте, отсутствует распознавание дубликатов, но об этом - следующий раздел.

Как избавиться от дубликатов писем в папке "Отправленные"

Итак, на этом этапе, остается одна нерешенная проблема - дубликаты отправленных. Решить эту проблему можно разными способами (включая написание своего плагина для Dovecot), но здесь будет рассмотрен способ опирающийся на Sieve и механизмы рефильтеринга.

Подробнее о Sieve, см. в соответствующей заметке - Dovecot 2 - Sieve.

Sieve - замечательное средство (к примеру Postfix не имеет поддержки подобного языка), но в простом варианте, его возможности ограничены только почтой, поступающей во "Входящие", и доставляемой через LDA/LMTP, поскольку подключение Sieve, и обработка им почты, происходит только в момент доставки.

ВАЖНО! Подключение плагина Sieve для протокола IMAP в Dovecot, - приводит к ошибке.

Это означает, что для обработки писем, которые уже находятся в папках (например, письма созданные IMAP), нужно использовать рефильтеринг - принудительное "перечитывание" через Sieve. Это можно было бы сделать, например с помощью инструмента командной строки sieve-filter.

К сожалению, в этом варианте есть одно "но". Некоторые расширения Sieve судя по-всему работают только с переменными окружения LDA-сессии. В частности, расширение vnd.dovecot.duplicate, отслеживающее дубликаты по Message-ID, и даже обычный redirect не срабатывают для писем, обрабатываемых sieve-filter. В этом случае, одним из способов заставить их работать, может быть использование повторной доставки этих писем через LDA.

Удаление входящих дубликатов с помощью Sieve, в момент доставки

Добавим расширение vnd.dovecot.duplicate

/etc/dovecot/conf.d/90-sieve.conf :

plugin {
...
  sieve_extensions = +vnd.dovecot.duplicate
  # sieve_global_extensions = +vnd.dovecot.duplicate
...
}

И переделаем скрипт из примера выше, добавив в него отслеживание дубликатов (добавленное выделено цветом).

/var/lib/dovecot/sieve/global/test.sieve :

require ["vnd.dovecot.duplicate", "editheader", "imap4flags", "fileinto", "envelope", "subaddress"];
if allof (not exists "X-Deduplicate", anyof (envelope :detail "to" "autobcc", not exists "Delivered-To")) {
    if duplicate {
        discard;
        stop;
    }
    else {
        if not exists "Delivered-To" {
            # addheader :last "X-Deduplicate" "IMAP refiltering";
            addheader "X-Deduplicate" "IMAP refiltering";
        }
        else {
            # addheader :last "X-Deduplicate" "autobcc";
            addheader "X-Deduplicate" "autobcc";
        }
        setflag "\\seen";

        fileinto "Sent";
    }
}

Кроме обнаружения писем авто-BCC, здесь добавлено if anyof ( ... , not exists "Delivered-To" ) { - дополнительное условие для обнаружения созданных IMAP (и повторно посланных через LDA) копий отправленных, а также добавлена вставка маркирующего заголовка "X-Deduplicate", и проверка на его отсутствие - об этом ниже. Кроме того, добавлена собственно проверка на дубликаты (отслеживает "Message-ID").
Аргумент :last (в закомментированных строках) указывает записать заголовок в конец секции заголовков, а не в началао.

Компилируем скрипт:
# sievec /var/lib/dovecot/sieve/global/test.sieve

Повторная отправка сохраненных IMAP отправленных через LDA

Идея здесь в том, чтобы отслеживать все письма попадающие в "Отправленные", анализировать заголовок, отделять только письма, сохраненные IMAP, и перенаправлять их на повторную доставку через LDA, давая возможность отработать проверке дубликатов в Sieve через расширение vnd.dovecot.duplicate. При этом письма, в которых уже присутствует маркирующий заголовок (упомянутый выше "X-Deduplicate" , означающий, что они уже прошли такую проверку) останутся как есть не затронуты.

Следить за папкой "Отправленные" и генерировать событие при попадании в нее письма, будет incron, а проверять создано ли письмо IMAP, и проходило ли оно уже проверку - инструмент командной строки sieve-test, который очень кстати дает возможность обрабатывать только один конкретный физический файл ("пойманный" incron).

incron (Incrontab) - позволяет отслеживать события файловой системы и сопоставлять им заданные действия (например вызывать скрипт). Как видно из названия - он похож на Cron, с той разницей что Cron инициируется часами, а incron - файловой системой.

Установим сам incron:

# apt-get install incron

Добавим "root" в список разрешенных.

# nano /etc/incron.allow :

root

Установим наблюдение за папкой "Отправленные". Вместо использования способа # incrontab -e , создадим отдельный файл в каталоге /etc/incron.d/ для получателя "user@domain.tld".
ВАЖНО! - Incrontab очень чувствителен к лишним символам пробелов, табуляции и комментариям

# nano /etc/incron.d/domain.tld-user :

/home/vmail/domain.tld/user/.Sent/cur/ IN_MOVED_TO /var/lib/dovecot/sent_refilter.sh /home/vmail/domain.tld/user/ user@domain.tld $#
Здесь будет задействован скрипт sent_refilter.sh (сам он приведен ниже), в который передается в качестве аргумента "$#" имя IN_MOVED_TO файла. Наблюдаемый incron каталог здесь - физический подкаталог формата Maildir .../cur/ .

Все аргументы, передаваемые в скрипт:

  1. /home/vmail/domain.tld/user/ - корневой почтовый каталог пользователя
  2. user@domain.tld - имя (логин) пользователя
  3. $# - имя файла, "отловленного" incron

КСТАТИ! Можно автоматизировать добавление/удаление файлов incron (подобных /etc/incron.d/domain.tld-user ), синхронизировав эти операции с событиями добавления/удаления пользователей в PostfixAdmin (используя тамошние пост-сценарии). Надо понимать что пост-сценарии запускаются НЕ от "root" (а скорее всего от "www-data"), как того требует incron. Поэтому имеет смысл использовать тот-же incron, для наблюдения за появлением/удалением пользователей, запуская/удаляя (уже от имени "root") по этим событиям скрипт наблюдения за соответствующими папками ящиков. Назначение папок tmp, new и cur формата Maildir - см. в Википедии. :)

Создадим сам shell-скрипт

# nano /var/lib/dovecot/sent_refilter.sh :

#!/bin/bash
qresult="$(sieve-test -l $1 /var/lib/dovecot/sieve/global/refiltering_sent.sieve $1/.Sent/cur/$3)"
if [[ "$qresult" == *discard* ]]
then
        /usr/lib/dovecot/dovecot-lda -d $2 -p $1/.Sent/cur/$3
        rm $1/.Sent/cur/$3
        doveadm index -u $2 mailbox Sent
fi

Отредактируем права:

# chmod 700 /var/lib/dovecot/sent_refilter.sh

В официальной документации, в примерах, для рефильтеринга предлагается использовать GetMail. Здесь в скрипте, для примера использованы штатные инструменты командной строки, позволяющие в аргументах использовать имя физического файла письма формата Maildir.
sieve-test после обработки указанного файла возвращает строку, содержащую discard в случае если файл подлежит рефильтерингу. Инструмент dovecot-lda позволяет сделать повторную доставку при известном пользователе и имени файла. Далее файл удаляется и происходит обновление индексов папки "Sent" с помощью doveadm index. Возможно идея с удалением файла и обновлением индексов - не самое красивое решение, но вполне рабочее.

КСТАТИ! Инструмент командной строки doveadm предоставляет массу интересных возможностей. Они сильно отличаются в разных версиях, поэтому можно посмотреть краткий список доступных, введя в консоли просто # doveadm help , либо как обычно # man doveadm .

Скрипт Sieve, обрабатывающий каждое письмо (для incron), попадающее в "Отправленные", может быть таким

# nano /var/lib/dovecot/sieve/global/refiltering_sent.sieve :

if not exists "X-Deduplicate" {
	discard;
	stop;
}

Компилируем скрипт:
# sievec /var/lib/dovecot/sieve/global/refiltering_sent.sieve

Конфиг LDA может быть таким (все остальное можно закомментировать)

/etc/dovecot/conf.d/15-lda.conf :

postmaster_address = postmaster@domain.tld
hostname = domain.tld
...
protocol lda {
# ...
  mail_plugins = sieve
# ...
}

Итак, после того, как в папке "Sent" появится любой файл, будет срабатывать incron, передавая имя файла письма в скрипт sent_refilter.sh, который проверит его, и если обнаружит, что это письмо не содержит маркирующего заголовка "X-Deduplicate", - отправит его на рефильтеринг через LDA к Sieve-скрипту, отслеживающему дубликаты (по "Message-ID") с помощью расширения vnd.dovecot.duplicate.

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

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

КСТАТИ! В последних релизах Dovecot, еще отсутствующих в репозитариях Debian, присутствует новые инструменты командной строки.
Например: "doveadm deduplicate", "doveadm exec" и пр.
Кроме того, в репозитариях Debian доступен интересный пакет libnet-sieve-script-perl, который дает возможность читать, анализировать и записывать Sieve-файл сценария, организуя доступ к правилам, действиям и условиям объектов.

См. также заметку с детальным описанием настройки конкретной, рассматриваемой в этой серии заметок, конфигурации: Полный пример установки всех пакетов и настройки конфигурационных файлов.

Также см. заметку Dovecot 2 - Sieve.

Источники

Источники информации и ссылки перечислены на отдельной странице, указанной внизу главной страницы темы:
Установка и настройка почтового сервера

Рекламные ссылки:
Комментариев: 8 RSS

Вариант одного sender_bss_maps с подзапросами.

1) Если домен неизвестен - пусто

2) Если известен, но нет пользователя - ящик unknownsender

3) Если известен - имя+autobcc@domain.tld

vi /etc/postfix/sql/mysql_verify_unferify_bcc_maps.cf

user = postfix

password = ***********

hosts = localhost

dbname = mail

query = select if ((SELECT count(domain) FROM domain WHERE domain='%d' AND active = '1') = 0,(select 1 from dual where false), (SELECT IF(COUNT(username) = 0, 'unknownsender@%d', CONCAT('%u', '+autobcc', '@', '%d')) FROM mailbox WHERE username='%s' AND active = '1'))

Алексей3
2014-07-22 в 13:54:37

Не подскажете, в чем может быть проблема?

Скрипт не отрабатывает

require ["fileinto", "envelope", "subaddress"];

if envelope :detail "to" "autobcc" {

fileinto "Sent";

}

А так да:

require ["fileinto", "envelope", "subaddress"];

fileinto "Sent";

То есть нет поля detail в глобальном скрипте как я понимаю.

autobcc точно присутствует.

Алексей

По-видимому в заголовке "to" нет куска строки "autobcc".

См. Способ 2 выше.

Алексей5
2014-07-22 в 15:18:39

Вот письмо, которое идет.

[root@mail cur]# cat '1406021691.M905970P6362.mail.pravoweek.info,S=486,W=501:2,S'

Return-Path:

Delivered-To: admin+autobcc@domain.info

Received: by mail.domain.info (Postfix, from userid 0)

id CA4011FD23; Tue, 22 Jul 2014 13:34:51 +0400 (MSK)

Date: Tue, 22 Jul 2014 13:34:51 +0400

From: admin@domain.info

To: a6y@anotherdomain.ru

Subject: Tstt

Message-ID:

User-Agent: Heirloom mailx 12.4 7/29/08

MIME-Version: 1.0

Content-Type: text/plain; charset=us-ascii

Content-Transfer-Encoding: 7bit

asd

У Вас не срабатывает условие в скрипте.

Аргумент ":detail" становится доступным после подключения расширения "subaddress".

К сожалению не вижу здесь у Вас никаких причин, по которым условие не срабатывает. Должно работать.

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

Upd:

Посмотрите правильно ли у Вас настроен параметр "recipient_delimiter" в файле конфигурации /etc/dovecot/conf.d/90-sieve.conf

Подробнее об этом параметре:

http://dummyluck.com/page/sieve_dovecot_2#configuration

"Разделитель, который ожидается между именем пользователя :user и :detail в части адреса, представленной расширением subaddress. Он может быть так же последовательностью символов (напр "--"). Текущая реализация ищет разделитель начиная слева до первого вхождения. После того как разделитель будет найден, та часть что слева от него считается именем пользователя :user, а часть, что справа - :detail. Этот параметр также используется в Dovecot-LMTP с идентичной семантикой."

Алексей7
2014-07-22 в 16:24:26

[root@mail log]# doveconf -n | grep recipient

recipient_delimiter = +

[root@mail log]# postconf -n | grep recipient

recipient_delimiter = +

Лог доставки:

Jul 22 17:20:38 mail postfix/pickup[8612]: 722E11FD38: uid=0 from=

Jul 22 17:20:38 mail postfix/cleanup[8742]: 722E11FD38: message-id=

Jul 22 17:20:38 mail postfix/qmgr[8613]: 722E11FD38: from=, size=420, nrcpt=2 (queue active)

Jul 22 17:20:38 mail postfix/pipe[8745]: 722E11FD38: to=, relay=dovecot, delay=0.28, delays=0.19/0.02/0/0.07, dsn=2.0.0, status=sent (delivered via dovecot service)

Jul 22 17:20:39 mail postfix/smtp[8744]: 722E11FD38: to=, relay=aspmx.l.google.com[173.194.71.26]:25, delay=0.85, delays=0.19/0.02/0.21/0.43, dsn=2.0.0, status=sent (250 2.0.0 OK 1406035239 dp4si792575lad.120 - gsmtp)

Jul 22 17:20:39 mail postfix/qmgr[8613]: 722E11FD38: removed

То есть заголовок to на этапе доставки to=. Но в сохраненном письме, как указано выше уже без

него

To: user@domain.tld

А это расширение subaddress нужно подключать как то специфически?

Нет, подключать специфически "subaddress" не нужно. Сам скрипт также 100% правильный (в т.ч. имя заголовка)

Всё что я пока могу предложить, это проверить recipient_delimeter в следующих файлах конфигурации:

/etc/dovecot/conf.d/90-sieve.conf

/etc/dovecot/conf.d/15-lda.conf

/etc/postfix/main.cf

Посмотрите также здесь:

http://dummyluck.com/page/debian_postfix_dovecot_2_config#dovecot_sieve_setting

(прокрутите раздел до списка задействованных в процессе файлов конфигурации)

Вопросы по теме статьи (просьба - без личностей), - присутствует премодерация:
   - регистрироваться НЕ обязательно! -

Комментарий будет опубликован только после проверки

Вы можете войти под своим логином или зарегистрироваться на сайте.

(обязательно)