[Sysadmins] local recipient table for postfix via dovecot passdb

[Sysadmins] local recipient table for postfix via dovecot passdb

[Eugene Prokopiev]

Здравствуйте!

Правильно ли я понимаю следующее?

Для проверки логина/пароля пользователя на предмет, разрешено ли ему 
оправлять почту вообще, можно использовать посредника (Dovecot SASL), 
который спросит у Dovecot, есть ли такие логин/пароль в passdb 
dovecot.conf. Т.е. имеется дополнительный уровань абстракции, благодаря 
которому Postfix не обязан знать, как именно эти логины/пароли описаны в 
Dovecot.

А вот local recipient table - это именно table, т.е. нужен прямой доступ 
к файлу логинов (или к таблице в БД), никаким посредником тут не 
обойтись. И поскольку Postfix понимает только один жесткий формат файла, 
не совпадающий с форматом файла паролей Dovecot, то придется держать 2 
файла, либо генерить один на основе другого, либо использовать sql/ldap?

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Vladimir V. Kamarzin]

>>>>> On 12 Nov 2007 at 18:28 "EP" == Eugene Prokopiev writes:

 EP> А вот local recipient table - это именно table, т.е. нужен прямой доступ 
 EP> к файлу логинов (или к таблице в БД), никаким посредником тут не 
 EP> обойтись. И поскольку Postfix понимает только один жесткий формат файла, 

Если использовать простые таблицы, типа cdb/hash, формат файла выглядит как:

If you use local files in postmap(1) format, then local_recipient_maps expects
the following table format:

  * In the left-hand side, specify a bare username, an "@domain.tld" wild-card,
    or specify a complete "user@domain.tld" address.

  * You have to specify something on the right-hand side of the table, but the
    value is ignored by local_recipient_maps.

 EP> не совпадающий с форматом файла паролей Dovecot, то придется держать 2 
 EP> файла, либо генерить один на основе другого, либо использовать sql/ldap?

В принципе можно вообще не использовать таблицы, а обойтись лишь recipient
verification, заведя отдельный restriction_class, в котором бы осуществлялась
проверка reject_unverified_recipient для локальных доменов. См. пример
http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX/recipientverification/rejectunverifiedrecipient?v=ze5&

Допустим, SMTP-клиент пытается залить нам мыло для юзера user@domain. Постфикс
генерирует конверт и пытается доставить его допустим по lmtp dovecot-у. Если
Dovecot говорит 550 user unknown, постфикс SMTP-клиента посылает тоже с 550, а
точнее, клиенту будет процитирован ответ dovecot-а. Соответственно, если
Dovecot говорит 450, SMTP-клиенту отдаётся тоже 450.

Подробнее см ADDRESS_VERIFICATION_README, man 8 verify.

-- 
vvk

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

Vladimir V. Kamarzin пишет:
...
> 
> В принципе можно вообще не использовать таблицы, а обойтись лишь recipient
> verification, заведя отдельный restriction_class, в котором бы осуществлялась
> проверка reject_unverified_recipient для локальных доменов. См. пример
> http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX/recipientverification/rejectunverifiedrecipient?v=ze5&
> 
> Допустим, SMTP-клиент пытается залить нам мыло для юзера user@domain. Постфикс
> генерирует конверт и пытается доставить его допустим по lmtp dovecot-у. Если
> Dovecot говорит 550 user unknown, постфикс SMTP-клиента посылает тоже с 550, а
> точнее, клиенту будет процитирован ответ dovecot-а. Соответственно, если
> Dovecot говорит 450, SMTP-клиенту отдаётся тоже 450.

  А можно ли вклиниться в эту идиллию так, чтобы при этом (срыве
доставки по lmtp) сообщения о недоставке (от MAILER-DAEMON@),
отправителю не уходили (кроме списка доменов заданного руками)?

> 
> Подробнее см ADDRESS_VERIFICATION_README, man 8 verify.
> 

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Vladimir V. Kamarzin]

>>>>> On 15 Nov 2007 at 02:52 "AA" == Aleksey Avdeev writes:

>> В принципе можно вообще не использовать таблицы, а обойтись лишь recipient
>> verification, заведя отдельный restriction_class, в котором бы осуществлялась
>> проверка reject_unverified_recipient для локальных доменов. См. пример
>> http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX/recipientverification/rejectunverifiedrecipient?v=ze5&
>> 
>> Допустим, SMTP-клиент пытается залить нам мыло для юзера user@domain. Постфикс
>> генерирует конверт и пытается доставить его допустим по lmtp dovecot-у. Если
>> Dovecot говорит 550 user unknown, постфикс SMTP-клиента посылает тоже с 550, а
>> точнее, клиенту будет процитирован ответ dovecot-а. Соответственно, если
>> Dovecot говорит 450, SMTP-клиенту отдаётся тоже 450.

 AA>   А можно ли вклиниться в эту идиллию так, чтобы при этом (срыве
 AA> доставки по lmtp) сообщения о недоставке (от MAILER-DAEMON@),
 AA> отправителю не уходили (кроме списка доменов заданного руками)?

Гмм, я вижу только один вариант "срыва доставки по lmtp", приводящий к
генерации баунсов: если в кэше результат проверки конкретного
реципиента положительный (status=deliverable), а MDA по какой-либо причине
перестал принимать почту для данного реципиента (например исчерпана квота,
юзера удалли, и т.п.), то постфикс будет слать баунсы на envelope-from до тех
пор, пока не истечёт время address_verify_positive_refresh_time (default:
7d). В общем, тут важно правильно подобрать параметры кэширования.

>> Подробнее см ADDRESS_VERIFICATION_README, man 8 verify.

-- 
vvk

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

Vladimir V. Kamarzin пишет:
>>>>>> On 15 Nov 2007 at 02:52 "AA" == Aleksey Avdeev writes:
> 
>>> В принципе можно вообще не использовать таблицы, а обойтись лишь recipient
>>> verification, заведя отдельный restriction_class, в котором бы осуществлялась
>>> проверка reject_unverified_recipient для локальных доменов. См. пример
>>> http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX/recipientverification/rejectunverifiedrecipient?v=ze5&
>>>
>>> Допустим, SMTP-клиент пытается залить нам мыло для юзера user@domain. Постфикс
>>> генерирует конверт и пытается доставить его допустим по lmtp dovecot-у. Если
>>> Dovecot говорит 550 user unknown, постфикс SMTP-клиента посылает тоже с 550, а
>>> точнее, клиенту будет процитирован ответ dovecot-а. Соответственно, если
>>> Dovecot говорит 450, SMTP-клиенту отдаётся тоже 450.
> 
>  AA>   А можно ли вклиниться в эту идиллию так, чтобы при этом (срыве
>  AA> доставки по lmtp) сообщения о недоставке (от MAILER-DAEMON@),
>  AA> отправителю не уходили (кроме списка доменов заданного руками)?
> 
> Гмм, я вижу только один вариант "срыва доставки по lmtp", приводящий к
> генерации баунсов: если в кэше результат проверки конкретного
> реципиента положительный (status=deliverable), а MDA по какой-либо причине
> перестал принимать почту для данного реципиента (например исчерпана квота,
> юзера удалли, и т.п.), то постфикс будет слать баунсы на envelope-from до тех
> пор, пока не истечёт время address_verify_positive_refresh_time (default:
> 7d). В общем, тут важно правильно подобрать параметры кэширования.

  Распишу подробнее:

1. В качестве imap сервера использую cyrus (не dovecot), и списком
пользователей владеет именно он.

2. Всю приходящую на домен почту (после всех поверок) -- postfix
пересылает cyrus`у по lmtp.

3. В качестве одного из промежуточных фильтров (до передачи по lmtp) --
используется amavis-new (который тоже в какой-то момент перестал
проставлять заголовки, но вирусы по прежнему ловит)...

  Пока писал, подумал что наблюдаемое вполне может быть из-за amavis`а
(и/или любого другого фильтра с отложенной обработкой), т. к. он
обрабатывает сообщения уже находящиеся в очереди postfix`а, _после_
завершения входящей SMTP сессии. Т. е. из-за использования в процессе
доставки фильтра обрабатывающего очередь, postfix получает отлуп от
принимающего по lmtp не в момент существования входящей SMTP сессии, а
уже после её завершения...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Vladimir V. Kamarzin]

>>>>> On 15 Nov 2007 at 15:07 "AA" == Aleksey Avdeev writes:

 AA> 1. В качестве imap сервера использую cyrus (не dovecot), и списком
 AA> пользователей владеет именно он.

 AA> 2. Всю приходящую на домен почту (после всех поверок) -- postfix
 AA> пересылает cyrus`у по lmtp.

 AA> 3. В качестве одного из промежуточных фильтров (до передачи по lmtp) --
 AA> используется amavis-new (который тоже в какой-то момент перестал
 AA> проставлять заголовки, но вирусы по прежнему ловит)...

 AA>   Пока писал, подумал что наблюдаемое вполне может быть из-за amavis`а
 AA> (и/или любого другого фильтра с отложенной обработкой), т. к. он
 AA> обрабатывает сообщения уже находящиеся в очереди postfix`а, _после_
 AA> завершения входящей SMTP сессии. Т. е. из-за использования в процессе
 AA> доставки фильтра обрабатывающего очередь, postfix получает отлуп от
 AA> принимающего по lmtp не в момент существования входящей SMTP сессии, а
 AA> уже после её завершения...

Контент-фильтры к sender/recipient verification отношения не имеют и не
влияют.

-- 
vvk

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Vladimir V. Kamarzin пишет:
>>>>>> On 15 Nov 2007 at 15:07 "AA" == Aleksey Avdeev writes:
> 
>  AA> 1. В качестве imap сервера использую cyrus (не dovecot), и списком
>  AA> пользователей владеет именно он.
> 
>  AA> 2. Всю приходящую на домен почту (после всех поверок) -- postfix
>  AA> пересылает cyrus`у по lmtp.
> 
>  AA> 3. В качестве одного из промежуточных фильтров (до передачи по lmtp) --
>  AA> используется amavis-new (который тоже в какой-то момент перестал
>  AA> проставлять заголовки, но вирусы по прежнему ловит)...
> 
>  AA>   Пока писал, подумал что наблюдаемое вполне может быть из-за amavis`а
>  AA> (и/или любого другого фильтра с отложенной обработкой), т. к. он
>  AA> обрабатывает сообщения уже находящиеся в очереди postfix`а, _после_
>  AA> завершения входящей SMTP сессии. Т. е. из-за использования в процессе
>  AA> доставки фильтра обрабатывающего очередь, postfix получает отлуп от
>  AA> принимающего по lmtp не в момент существования входящей SMTP сессии, а
>  AA> уже после её завершения...
> 
> Контент-фильтры к sender/recipient verification отношения не имеют и не
> влияют.
> 

  Тогда что-то не понимаю...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Vladimir V. Kamarzin]

>>>>> On 16 Nov 2007 at 13:11 "AA" == Aleksey Avdeev writes:

>> Контент-фильтры к sender/recipient verification отношения не имеют и не
>> влияют.

 AA>   Тогда что-то не понимаю...

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

-- 
vvk

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

Vladimir V. Kamarzin пишет:
>>>>>> On 16 Nov 2007 at 13:11 "AA" == Aleksey Avdeev writes:
> 
>>> Контент-фильтры к sender/recipient verification отношения не имеют и не
>>> влияют.
> 
>  AA>   Тогда что-то не понимаю...
> 
> Похоже что так. Попробуйте сформулировать проблему поточнее, с логами и пр.
> 

  Пока не готов. (Не до того...)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Anton Kvashin]

Aleksey Avdeev пишет:
> Vladimir V. Kamarzin пишет:
>>>>>>> On 15 Nov 2007 at 02:52 "AA" == Aleksey Avdeev writes:
>>>> В принципе можно вообще не использовать таблицы, а обойтись лишь recipient
>>>> verification, заведя отдельный restriction_class, в котором бы осуществлялась
>>>> проверка reject_unverified_recipient для локальных доменов. См. пример
>>>> http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX/recipientverification/rejectunverifiedrecipient?v=ze5&
>>>>
>>>> Допустим, SMTP-клиент пытается залить нам мыло для юзера user@domain. Постфикс
>>>> генерирует конверт и пытается доставить его допустим по lmtp dovecot-у. Если
>>>> Dovecot говорит 550 user unknown, постфикс SMTP-клиента посылает тоже с 550, а
>>>> точнее, клиенту будет процитирован ответ dovecot-а. Соответственно, если
>>>> Dovecot говорит 450, SMTP-клиенту отдаётся тоже 450.
>>  AA>   А можно ли вклиниться в эту идиллию так, чтобы при этом (срыве
>>  AA> доставки по lmtp) сообщения о недоставке (от MAILER-DAEMON@),
>>  AA> отправителю не уходили (кроме списка доменов заданного руками)?
>>
>> Гмм, я вижу только один вариант "срыва доставки по lmtp", приводящий к
>> генерации баунсов: если в кэше результат проверки конкретного
>> реципиента положительный (status=deliverable), а MDA по какой-либо причине
>> перестал принимать почту для данного реципиента (например исчерпана квота,
>> юзера удалли, и т.п.), то постфикс будет слать баунсы на envelope-from до тех
>> пор, пока не истечёт время address_verify_positive_refresh_time (default:
>> 7d). В общем, тут важно правильно подобрать параметры кэширования.
> 
>   Распишу подробнее:
> 
> 1. В качестве imap сервера использую cyrus (не dovecot), и списком
> пользователей владеет именно он.

Он может видеть/использовать список пользователей из sql/ldap, т.е.
не единоличное владение.

> 2. Всю приходящую на домен почту (после всех поверок) -- postfix
> пересылает cyrus`у по lmtp.

Не использую postfix, но по памяти virtual_table можно направить в
sql/ldap. И он на этапе rcpt to (если postfix может такое) говорить
550 unknown user.

> 3. В качестве одного из промежуточных фильтров (до передачи по lmtp) --
> используется amavis-new (который тоже в какой-то момент перестал
> проставлять заголовки, но вирусы по прежнему ловит)...
> 
>   Пока писал, подумал что наблюдаемое вполне может быть из-за amavis`а
> (и/или любого другого фильтра с отложенной обработкой), т. к. он
> обрабатывает сообщения уже находящиеся в очереди postfix`а, _после_
> завершения входящей SMTP сессии. Т. е. из-за использования в процессе
> доставки фильтра обрабатывающего очередь, postfix получает отлуп от
> принимающего по lmtp не в момент существования входящей SMTP сессии, а
> уже после её завершения...

Посмотрите exim. Он позволяет делать контентную фильтрацию в
SMTP-сессии на этапе DATA, без прослоек.

-- 
Anton Kvashin

Re: [Sysadmins] local recipient table for postfix via dovecot passdb

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

Anton Kvashin пишет:
> Aleksey Avdeev пишет:
>> Vladimir V. Kamarzin пишет:
>>>>>>>> On 15 Nov 2007 at 02:52 "AA" == Aleksey Avdeev writes:
>>>>> В принципе можно вообще не использовать таблицы, а обойтись лишь recipient
>>>>> verification, заведя отдельный restriction_class, в котором бы осуществлялась
>>>>> проверка reject_unverified_recipient для локальных доменов. См. пример
>>>>> http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX/recipientverification/rejectunverifiedrecipient?v=ze5&
>>>>>
>>>>> Допустим, SMTP-клиент пытается залить нам мыло для юзера user@domain. Постфикс
>>>>> генерирует конверт и пытается доставить его допустим по lmtp dovecot-у. Если
>>>>> Dovecot говорит 550 user unknown, постфикс SMTP-клиента посылает тоже с 550, а
>>>>> точнее, клиенту будет процитирован ответ dovecot-а. Соответственно, если
>>>>> Dovecot говорит 450, SMTP-клиенту отдаётся тоже 450.
>>>  AA>   А можно ли вклиниться в эту идиллию так, чтобы при этом (срыве
>>>  AA> доставки по lmtp) сообщения о недоставке (от MAILER-DAEMON@),
>>>  AA> отправителю не уходили (кроме списка доменов заданного руками)?
>>>
>>> Гмм, я вижу только один вариант "срыва доставки по lmtp", приводящий к
>>> генерации баунсов: если в кэше результат проверки конкретного
>>> реципиента положительный (status=deliverable), а MDA по какой-либо причине
>>> перестал принимать почту для данного реципиента (например исчерпана квота,
>>> юзера удалли, и т.п.), то постфикс будет слать баунсы на envelope-from до тех
>>> пор, пока не истечёт время address_verify_positive_refresh_time (default:
>>> 7d). В общем, тут важно правильно подобрать параметры кэширования.
>>   Распишу подробнее:
>>
>> 1. В качестве imap сервера использую cyrus (не dovecot), и списком
>> пользователей владеет именно он.
> 
> Он может видеть/использовать список пользователей из sql/ldap, т.е.
> не единоличное владение.

  На данный момент они у меня в sasldb.

> 
>> 2. Всю приходящую на домен почту (после всех поверок) -- postfix
>> пересылает cyrus`у по lmtp.
> 
> Не использую postfix, но по памяти virtual_table можно направить в
> sql/ldap. И он на этапе rcpt to (если postfix может такое) говорить
> 550 unknown user.

  Это знаю, но для этого сначала нужно перейти на sql/ldap (что в
планах, но не быстрых).

> 
>> 3. В качестве одного из промежуточных фильтров (до передачи по lmtp) --
>> используется amavis-new (который тоже в какой-то момент перестал
>> проставлять заголовки, но вирусы по прежнему ловит)...
>>
>>   Пока писал, подумал что наблюдаемое вполне может быть из-за amavis`а
>> (и/или любого другого фильтра с отложенной обработкой), т. к. он
>> обрабатывает сообщения уже находящиеся в очереди postfix`а, _после_
>> завершения входящей SMTP сессии. Т. е. из-за использования в процессе
>> доставки фильтра обрабатывающего очередь, postfix получает отлуп от
>> принимающего по lmtp не в момент существования входящей SMTP сессии, а
>> уже после её завершения...
> 
> Посмотрите exim. Он позволяет делать контентную фильтрацию в
> SMTP-сессии на этапе DATA, без прослоек.
> 

  OK, может быть гляну.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]