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

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

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

jim@theidsp.net @theidsp-network.inter-realm.net,jim@space-port-pros.com

Таким образом, письма, отправленные на адрес jim@theidsp.net, перенаправляются как на jim@theidsp-network.inter-realm.net и jim@space-port-pros.com. Работает корректно уже много лет.

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

После обновления постфикса smtpd, кажется, пытается перенаправить на единственный получатель "jim@theidsp-network.inter-realm.net,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 = jimays@theidsp.net
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,jim@space-port-pros.com
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
 key=jimays@theidsp.net -> status=0 result=@theidsp-network.inter-realm.net,jim@space-port-pros.com
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): jimays@theidsp.net = @theidsp-network.inter-realm.net,jim@space-port-pros.com
14 апреля 10:45:17 mail7-057 sslmx/smtpd[8640]: mail_addr_find: jimays@theidsp.net -> @theidsp-network.inter-realm.net,jim@space-port-pros.com
...
14 апреля 10:45:17 mail7-057 postfix/smtp[8669]: 55E65C895: to=<"jimays@theidsp-network.inter-realm.net,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 на jim@space-port-pros.com и одна через транспорт 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=<WA3MAMA123eckpFEkmh003ec3a4@wa3mama123.IACP.DC>
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- c3ce593994a7@trumail7.inter-diversity-space-port.net>, 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=<jim@space-port-pros.com>, 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=<WA3MAMA123eckpFEkmh003ec3a4@wa3mama123.IACP.DC>
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- c3ce593994a7@trumail7.inter-diversity-space-port.net>, 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=<jimays@theidsp-network.inter-realm.net>, 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='jimays@theidsp.net';
+---------------+------------+-------------+------ ------------------------+-+--+------ -----+-----------------------------------+--------- -----------------------------------+------------------------+---- ----+
| forwarding_id | sys_userid | sys_groupid | sys_perm_user | sys_perm_group | sys_perm_other | идентификатор_сервера | источник | пункт назначения | тип | активный |
+---------------+------------+-------------+------ ------------------------+-+--+------ -----+-----------------------------------+--------- -----------------------------------+------------------------+---- ----+
| 201 | 2 | 2 | риуд | риуд | | 69 | jimays@theidsp.net | @theidsp-network.inter-realm.net,jim@space-port-pros.com | вперед | у |
+---------------+------------+-------------+------ ------------------------+-+--+------ -----+-----------------------------------+--------- -----------------------------------+------------------------+---- ----+
1 ряд в сете (0,001 сек)

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

dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_forwardings.cf flags=lock|fold_fix|utf8_request
 key=jimays@theidsp.net -> status=0 result=@theidsp-network.inter-realm.net,jim@space-port-pros.com
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): jimays@theidsp.net = @theidsp-network.inter-realm.net,jim@space-port-pros.com
20 апреля 16:44:37 mail7-057 sslmx/smtpd[9561]: mail_addr_find: jimays@theidsp.net -> @theidsp-network.inter-realm.net,jim@space-port-pros.com

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

Он столкнулся с этим тогда и только при использовании формы «@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) ("fails@e.invalid", "@e.invalid,b@e.invalid");
ВСТАВИТЬ В ЗНАЧЕНИЯ repro(s,d) ("works@e.invalid", "a@e.invalid,b@e.invalid");
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("","works@e.invalid", "")' | питон3
printf %b 'импорт smtplib;\nsmtplib.SMTP("::1").sendmail("","fails@e.invalid", "")' | питон3
# проверить логи