после обновления postfix 3.5.6 виртуальные сопоставления псевдонимов с несколькими получателями обрабатываются как отдельные имена, содержащие запятую

Только что обновился до debian bullseye postfix 3.5.6 с debian wheezy postfix 2.9.6.

Мы используем карты виртуальных псевдонимов для нескольких получателей, например:

[email protected] @theidsp-network.inter-realm.net,[email protected]

Таким образом, письма, отправленные на адрес [email protected], перенаправляются как на [email protected] и [email protected]. Работает корректно уже много лет.

Ранее мы узнали от http://www.postfix.org/virtual.5.html что порядок нескольких получателей важен. «Когда результат имеет форму @otherdomain, результатом становится тот же пользователь в otherdomain. Это работает только для первого адреса в результате поиска по нескольким адресам». Таким образом, мы ставим подстановочный знак @ получателя первым.

После обновления постфикса smtpd, кажется, пытается перенаправить на единственный получатель "[email protected],jim"@space-port-pros.com.

Поскольку пользователь не существует, эта почта попадает в общий список.

Вот некоторый вывод из mail.log:

14 апр 10:45:17 mail7-057 sslmx/smtpd[8640]: подключиться к подсистеме private/proxymap
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: отправить запрос attr = поиск
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: отправить таблицу attr = mysql:/etc/postfix/mysql-virtual_forwardings.cf
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: отправить флаги attr = 540736
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: отправить ключ attr = [email protected]
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: сокет private/proxymap: требуется атрибут: статус
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: имя входного атрибута: статус
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: значение входного атрибута: 0
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: сокет private/proxymap: требуемый атрибут: значение
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: имя входного атрибута: значение
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: значение входного атрибута: @theidsp-network.inter-realm.net,[email protected]
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: сокет private/proxymap: требуемый атрибут: (разделитель списка)
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: имя входного атрибута: (конец)
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_forwardings.cf flags=lock|fold_fix|utf8_request
 [email protected] -> status=0 [email protected],[email protected]
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: maps_find: virtual_alias_maps: proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf(0,lock|fold_fix|utf8
_request): [email protected] = @theidsp-network.inter-realm.net,[email protected]
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: mail_addr_find: [email protected] -> @theidsp-network.inter-realm.net,[email protected]
...
14 апреля 10:45:17 mail7-057 postfix/smtp[8669]: 55E65C895: to=<"[email protected],jim"@space-port-pros.com>, orig_to=< джимайс@теидс
p.net>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, задержка=0,06, задержки=0,01/0,02/0,01/0,02, dsn=2.0.0, статус=отправлено (250 2.0.0 Хорошо: в очереди как 5F628
А882)

Вот фрагменты из журнала за июнь, показывающие, что переадресация ранее приводила к двум различным строкам со статусом = отправлено, одна через транспорт smtp на [email protected] и одна через транспорт lmtp-g на jimays@theidsp-network. .inter-realm.net.

20 июня 06:30:58 mail7-057 sslmx/smtpd[28956]: подключиться с mail7-055.idsp56.net[192.168.56.55]
20 июня, 06:30:58 mail7-057 sslmx/smtpd[28956]: установлено анонимное TLS-соединение с mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 с шифром AECDH-AES256-SHA (256/256 бит )
20 июня 06:30:58 mail7-057 sslmx/smtpd[28956]: B91A42BE4: client=mail7-055.idsp56.net[192.168.56.55]
20 июня, 06:30:58 mail7-057 cleanup-srs/cleanup[28963]: B91A42BE4: message-id=<[email protected]>
20 июня 06:30:58 mail7-057 postfix/qmgr[19327]: B91A42BE4: from=<SRS0=Z5tX=LO=connect.match.com=bounces-MA-1-858-ea0868c4-498f-401a-b6f1- [email protected]>, size=47942, nrcpt=2 (очередь активна)
20 июня 06:30:58 mail7-057 sslmx/smtpd[28956]: отключиться от mail7-055.idsp56.net[192.168.56.55]
20 июня 06:30:58 mail7-057 postfix/smtp[28966]: установлено анонимное TLS-соединение с mail7-052.idsp56.net[192.168.56.52]:52025: TLSv1.2 с шифром AECDH-AES256-SHA (256/ 256 бит)
20 июня, 06:30:58 mail7-057 lmtp-g/lmtp[28965]: установлено доверенное TLS-соединение с lmtp7-g.inter-diversity-space-port.net[216.184.19.228]:64007: TLSv1 с шифром AES256- SHA (256/256 бит)
20 июня 06:30:58 mail7-057 postfix/smtp[28966]: B91A42BE4: to=<[email protected]>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, задержка = 0,16, задержки = 0,04/0,02/0,02/0,08, dsn = 2.0.0, статус = отправлено (250 2.0.0 OK: в очереди как C66855B94)
20 июня 06:30:59 mail7-057 sslmx/smtpd[28956]: подключиться с mail7-055.idsp56.net[192.168.56.55]
20 июня, 06:30:59 mail7-057 sslmx/smtpd[28956]: установлено анонимное TLS-соединение с mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 с шифром AECDH-AES256-SHA (256/256 бит )
20 июня 06:30:59 mail7-057 sslmx/smtpd[28956]: 9D1D12CA5: client=mail7-055.idsp56.net[192.168.56.55]
20 июня, 06:30:59 mail7-057 cleanup-srs/cleanup[28963]: 9D1D12CA5: message-id=<[email protected]>
20 июня 06:30:59 mail7-057 postfix/qmgr[19327]: 9D1D12CA5: from=<SRS0=Z5tX=LO=connect.match.com=bounces-MA-1-858-ea0868c4-498f-401a-b6f1- [email protected]>, size=50423, nrcpt=1 (очередь активна)
20 июня 06:30:59 mail7-057 sslmx/smtpd[28956]: отключиться от mail7-055.idsp56.net[192.168.56.55]
20 июня 06:31:07 mail7-057 lmtp-g/lmtp[28965]: B91A42BE4: to=<[email protected]>, relay=lmtp7-g.inter-diversity-space-port .net[216.184.19.228]:64007, задержка=8,9, задержки=0,04/0,02/0,12/8,7, dsn=2.0.0, статус=отправлено (250 ОК)
20 июня 06:31:07 mail7-057 postfix/qmgr[19327]: B91A42BE4: удалено

http://www.postfix.org/COMPATIBILITY_README.html не упомянул ничего конкретного об изменении поведения в картах виртуальных псевдонимов.

mysql-virtual_forwardings.cf имеет стандартный формат, созданный ISPConfig.

пользователь = ispconfig
пароль = отредактирован
имя_базы = idsp_mail7_062
таблица = mail_forwarding
select_field = пункт назначения
где_поле = источник
дополнительные_условия = и активные = 'y' и server_id = 81
хосты = 192.168.56.121

Соответствующая часть main.cf, которая вызывает файл:

virtual_alias_maps = regexp:/etc/postfix/regexp-virtual_forwardings__admin.cf, proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, proxy:mysql:/etc
/postfix/mysql-virtual_email2email.cf

Таблица virtual_forwardings выглядит так:

MariaDB [idsp_mail7_057]> выберите * из mail_forwarding, где source='[email protected]';
+---------------+------------+-------------+------ ------------------------+-+--+------ -----+-----------------------------------+--------- -----------------------------------+------------------------+---- ----+
| forwarding_id | sys_userid | sys_groupid | sys_perm_user | sys_perm_group | sys_perm_other | идентификатор_сервера | источник | пункт назначения | тип | активный |
+---------------+------------+-------------+------ ------------------------+-+--+------ -----+-----------------------------------+--------- -----------------------------------+------------------------+---- ----+
| 201 | 2 | 2 | риуд | риуд | | 69 | [email protected] | @theidsp-network.inter-realm.net,[email protected] | вперед | у |
+---------------+------------+-------------+------ ------------------------+-+--+------ -----+-----------------------------------+--------- -----------------------------------+------------------------+---- ----+
1 ряд в сете (0,001 сек)

Увеличено ведение журнала smtpd -v -v, и это отображается в журнале:

dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_forwardings.cf flags=lock|fold_fix|utf8_request
 [email protected] -> status=0 [email protected],[email protected]
20 апреля 16:44:37 mail7-057 sslmx/smtpd[9561]: maps_find: virtual_alias_maps: proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf(0,lock|fold_fix|utf8
_request): [email protected] = @theidsp-network.inter-realm.net,[email protected]
20 апреля 16:44:37 mail7-057 sslmx/smtpd[9561]: mail_addr_find: [email protected] -> @theidsp-network.inter-realm.net,[email protected]

поэтому кажется, что поиск происходит правильно, а то все равно бывает только одна рассылка вместо двух.

Он столкнулся с этим тогда и только при использовании формы «@otherdomain», поэтому можно обойти:

1. путем миграции с устаревшего таблица/выберите_поле/.. форма для указания запрос в вашей mysql-*.cf файл и имитировать в SQL то, что постфикс больше не делает, или
2. навсегда изменив свою таблицу, чтобы полностью расширить эти псевдонимы пользователь@домен форма.

Оба обходных пути будут включать запрос, содержащий что-то вроде CASE WHEN пункт назначения LIKE "@%" THEN SUBSTR(источник,1,INSTR(источник,"@"))||пункт назначения ELSE пункт назначения END чтобы позволить SQL просто объединить исходный почтовый ящик, если поиск начинается с @. Тщательно продумайте, что должно произойти с такими расширениями адресов, как пользователь+расширения@onedomain, если вы их используете!

При поиске возможных причин измененного поведения я наткнулся на некоторые переделки rfc822 в кавычках/без кавычек, которые май быть актуальным, CHANGELOG упоминает:

правильно распространять расширение адреса

с "aa bb+ext"@example.com на "cc dd+ext"@other.example

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

Мне удалось воспроизвести эту путаницу с типом списка/почтового ящика в Postfix 3.4.13 (распространяемом Ubuntu), используя либо запрос и таблица/выберите_поле/.., с или без проксимап, либо с многострочным результатом, либо с одним результатом, разделенным запятыми. Возможно, вы сможете выполнить следующие почти рабочие шаги в работающем репродукторе, чтобы сообщить о восходящем потоке. Очевидно выполняйте эти шаги только на тестовом поле.

выход 1 # ПОТЕРЯ ДАННЫХ! ЗАПУСКАТЬ ТОЛЬКО НА ВИРТУАЛЬНОЙ МАШИНЕ ДЛЯ ТЕСТИРОВАНИЯ!
postconf virtual_transport = ошибка
postconf virtual_alias_maps=proxy:sqlite:/etc/postfix/repro.cf
postconf virtual_alias_domains=e.invalid
postconf debug_peer_list=[::1]
sqlite3 /etc/postfix/repro.sqlite3 <<'EOF'
CREATE TABLE repro(s text, d text);
ВСТАВИТЬ В ЗНАЧЕНИЯ repro(s,d) ("[email protected]", "@e.invalid,[email protected]");
ВСТАВИТЬ В ЗНАЧЕНИЯ repro(s,d) ("[email protected]", "[email protected],[email protected]");
EOF
кошка >/etc/postfix/repro.cf <<'EOF'
dbpath=/etc/postfix/repro.sqlite3
query=SELECT d FROM repro WHERE s='%s'
EOF
# отправить тестовую почту (smtp не setuid, т.к. smtp создает более качественные журналы)
printf %b 'импорт smtplib;\nsmtplib.SMTP("::1").sendmail("","[email protected]", "")' | питон3
printf %b 'импорт smtplib;\nsmtplib.SMTP("::1").sendmail("","[email protected]", "")' | питон3
# проверить логи