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

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

В заметке разобраны варианты использования свойства 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.

Источники

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

Рекламные ссылки:
Комментариев: 13 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

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

Алексей9
2018-12-21 в 03:55:21

Здравствуйте! Статья понравилась, но все же это немного не то, что я искал. Пару лет назад я видел вариант с созданием дополнительной очереди в postfix путем редактирования master.cf. Тогда я еще пугался вида master.cf. У меня установлен postfix на локальной машине. По сути там fetchmail, postfix, dovecot, sieve. Postfix отправляет через письма в зависимость от указанного отправитеся через почтовые ящики на внешних серверах, используя smtp_sasl_auth_enable, smtp_sasl_password_maps, smtp_sender_dependent_authentication и sender_dependent_relayhost_maps. В общем хочется просто всю исходящую почту положить во входящие и отработать на ней sieve. Не подскажите, как такое можно реализовать без BCC, ибо оно немного не для того, как мне кажется. И желательно чтобы само письмо осталось нетронутым, как есть, как будто его туда MUA скопировал.

Алексей

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

Алексей11
2018-12-21 в 19:40:15

Спасибо за ваш ответ!

Наверно я не точно выразился. Sieve это просто решение для того, чтобы положить входящие куда надо и снять с таких писем флаг непрочитанных, когда входящие будут доставлены Dovecot-ом обратно в Inbox. Меня интересуют только настройки Postfix. Если не найду тот способ с master.cf, то может быть настрою через BCC. Нельзя ли отправляемые сообщения и запихивать их в тот же dovecot? Мой путь - унификация, независимость от MUA (все они подсоединяются к localhost:imap|smtp), единые правила разбора почты (Sieve), и все на стационарном компе - на сервере почту не держу принципиально, кроме тех случаев, когда я в поездке.

Алексей

Если нужна независимость от MUA, унификация, то другого пути кроме BCC не вижу.

Либо надо использовать только какой-то один MUA (например с вебинтерфейсом).

Алексей13
2018-12-25 в 19:26:51

> Либо надо использовать только какой-то один MUA (например с вебинтерфейсом).

Это точно не подойдет, мне нравится так, как у меня сейчас - чем удобно тем и захожу, не ограничивая себя в инструментах.

И, кажется, я нашел тот способ (не уверен, что это он), если вам интересно: http://www.opennet.ru/base/net/postfix_bcc_copy.txt.html

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

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

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

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