Только что обновился до 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. Это работает только для первого адреса в результате поиска по нескольким адресам". Поэтому мы ставим подстановочный знак @ получатель первым.
После обновления postfix smtpd, похоже, пытается переслать сообщение одному получателю.[email protected],jim"@space-port-pros.com.
Поскольку пользователь не существует, это письмо попадает в общую почту.
Вот некоторые выводы из mail.log:
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: connect to subsystem private/proxymap
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr request = lookup
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr table = mysql:/etc/postfix/mysql-virtual_forwardings.cf
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr flags = 540736
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr key = [email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: wanted attribute: status
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute name: status
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute value: 0
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: wanted attribute: value
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute name: value
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute value: @theidsp-network.inter-realm.net,[email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: wanted attribute: (list terminator)
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute name: (end)
Apr 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]
Apr 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]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: mail_addr_find: [email protected] -> @theidsp-network.inter-realm.net,[email protected]
...
Apr 14 10:45:17 mail7-057 postfix/smtp[8669]: 55E65C895: to=<"[email protected],jim"@space-port-pros.com>, orig_to=<jimays@theids
p.net>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, delay=0.06, delays=0.01/0.02/0.01/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5F628
A882)
Вот фрагменты из журнала за июнь, показывающие, что ранее пересылка приводила к двум отдельным строкам со статусом = отправлено, одна через транспорт SMTP на[email protected]и один через транспорт lmtp-g в[email protected].
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: connect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: Anonymous TLS connection established from mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: B91A42BE4: client=mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:58 mail7-057 cleanup-srs/cleanup[28963]: B91A42BE4: message-id=<[email protected]>
Jun 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-dimensional-space-port.net>, size=47942, nrcpt=2 (queue active)
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: disconnect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:58 mail7-057 postfix/smtp[28966]: Anonymous TLS connection established to mail7-052.idsp56.net[192.168.56.52]:52025: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Jun 20 06:30:58 mail7-057 lmtp-g/lmtp[28965]: Trusted TLS connection established to lmtp7-g.inter-dimensional-space-port.net[216.184.19.228]:64007: TLSv1 with cipher AES256-SHA (256/256 bits)
Jun 20 06:30:58 mail7-057 postfix/smtp[28966]: B91A42BE4: to=<[email protected]>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, delay=0.16, delays=0.04/0.02/0.02/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C66855B94)
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: connect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: Anonymous TLS connection established from mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: 9D1D12CA5: client=mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:59 mail7-057 cleanup-srs/cleanup[28963]: 9D1D12CA5: message-id=<[email protected]>
Jun 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-dimensional-space-port.net>, size=50423, nrcpt=1 (queue active)
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: disconnect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:31:07 mail7-057 lmtp-g/lmtp[28965]: B91A42BE4: to=<[email protected]>, relay=lmtp7-g.inter-dimensional-space-port.net[216.184.19.228]:64007, delay=8.9, delays=0.04/0.02/0.12/8.7, dsn=2.0.0, status=sent (250 Ok)
Jun 20 06:31:07 mail7-057 postfix/qmgr[19327]: B91A42BE4: removed
Thehttp://www.postfix.org/COMPATIBILITY_README.htmlне упомянул ничего конкретного об изменении поведения в виртуальных картах псевдонимов.
mysql-virtual_forwardings.cf имеет стандартный формат, созданный ISPConfig.
user = ispconfig
password = redacted
dbname = idsp_mail7_062
table = mail_forwarding
select_field = destination
where_field = source
additional_conditions = and active = 'y' and server_id = 81
hosts = 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]> select * from mail_forwarding where source='[email protected]';
+---------------+------------+-------------+---------------+----------------+----------------+-----------+--------------------+----------------------------------------------------------+---------+--------+
| forwarding_id | sys_userid | sys_groupid | sys_perm_user | sys_perm_group | sys_perm_other | server_id | source | destination | type | active |
+---------------+------------+-------------+---------------+----------------+----------------+-----------+--------------------+----------------------------------------------------------+---------+--------+
| 201 | 2 | 2 | riud | riud | | 69 | [email protected] | @theidsp-network.inter-realm.net,[email protected] | forward | y |
+---------------+------------+-------------+---------------+----------------+----------------+-----------+--------------------+----------------------------------------------------------+---------+--------+
1 row in set (0.001 sec)
Увеличил ведение журнала до 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]
Apr 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]
Apr 20 16:44:37 mail7-057 sslmx/smtpd[9561]: mail_addr_find: [email protected] -> @theidsp-network.inter-realm.net,[email protected]
таким образом, кажется, что поиск происходит правильно, но затем вместо двух происходит только одна отправка.
решение1
Он столкнулся с этим только тогда, когда использовал форму "@otherdomain", поэтому онможно было бы обойти:
- путем перехода от устаревшей
table/select_field/..
формы к указаниюquery
в вашемmysql-*.cf
файле и имитации в SQL того, что postfix больше не делает, или - путем постоянного изменения вашей таблицы, чтобы расширить эти псевдонимы до полной
user@domain
формы.
Оба решения предполагают запрос, содержащий что-то вроде того, CASE WHEN destination LIKE "@%" THEN SUBSTR(source,1,INSTR(source,"@"))||destination ELSE destination END
чтобы позволить SQL просто объединить исходный почтовый ящик, если поиск начинается с @.
Тщательно продумайте, что следует сделать с расширениями типа user+extensions@onedomain
, если вы их используете!
При поиске возможных причин изменившегося поведения я наткнулся на некоторые переделки кавычек/раскавычек rfc822, которыеможетбыть актуальным, CHANGELOG упоминает:
правильно распространять расширение адреса
с "aa bb+доб"@example.com на "cc dd+доб"@other.example
Хотя можно было бы с таким же успехом утверждать, что весьфункция, которая работает только при выполнении для первой записи в списке адресовthing — это ошибка в первую очередь. Такой шаг постобработки должен применяться ко всем элементам набора результатов без какой-либо возможной двусмысленности между почтовым ящиком/расширением/разделителем.
Мне удалось воспроизвести эту путаницу с типами списков и почтовых ящиков в Postfix 3.4.13 (в дистрибутиве Ubuntu) с помощью query
и table/select_field/..
, с или безпроксикарта, и либо с многострочным результатом, либо с одним разделенным запятой результатом. Вы можете быть в состоянии работать со следующими почти рабочими шагами в работающем воспроизводителе для отчета вверх по течению. Очевидновыполняйте эти шаги только на тестовом устройстве.
exit 1 # DATA LOSS! ONLY RUN ON VIRTUAL MACHINE FOR TESTING!
postconf virtual_transport=error
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);
INSERT INTO repro(s,d) VALUES ("[email protected]", "@e.invalid,[email protected]");
INSERT INTO repro(s,d) VALUES ("[email protected]", "[email protected],[email protected]");
EOF
cat >/etc/postfix/repro.cf <<'EOF'
dbpath=/etc/postfix/repro.sqlite3
query=SELECT d FROM repro WHERE s='%s'
EOF
# send test mail (smtp not setuid, because smtp produces nicer logs)
printf %b 'import smtplib;\nsmtplib.SMTP("::1").sendmail("","[email protected]", "")' | python3
printf %b 'import smtplib;\nsmtplib.SMTP("::1").sendmail("","[email protected]", "")' | python3
# check logs