Acabei de atualizar para o debian bullseye postfix 3.5.6 do debian wheezy postfix 2.9.6.
Usamos mapas de alias virtuais para vários destinatários, como este:
[e-mail protegido]@theidsp-network.inter-realm.net,[e-mail protegido]
Assim, os e-mails enviados para[e-mail protegido]são encaminhados tanto para [e-mail protegido]e para[e-mail protegido]. Há anos que funciona corretamente.
Anteriormente aprendemos comhttp://www.postfix.org/virtual.5.htmlque a ordem dos múltiplos destinatários é importante. "Quando o resultado tem o formato @otherdomain, o resultado se torna o mesmo usuário em otherdomain. Isso funciona apenas para o primeiro endereço em um resultado de pesquisa de vários endereços." Portanto, colocamos o curinga @ destinatário primeiro.
Após a atualização do postfix, o smtpd parece estar tentando encaminhar para um único destinatário "[e-mail protegido],jim"@space-port-pros.com.
Como o usuário não existe, este e-mail está sendo descartado.
Aqui estão alguns resultados do 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)
Aqui estão trechos de um log de junho mostrando que o encaminhamento resultou anteriormente em duas linhas distintas com status=sent, uma via transporte smtp para[e-mail protegido]e um via transporte lmtp-g para[e-mail protegido].
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
Ohttp://www.postfix.org/COMPATIBILITY_README.htmlnão mencionou nada específico sobre uma mudança de comportamento em mapas de alias virtuais.
mysql-virtual_forwardings.cf está em um formato padrão criado por 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
A parte pertinente do main.cf que invoca o arquivo é:
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
A tabela virtual_forwardings se parece com:
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)
Aumento do registro em smtpd -v -v e isso é mostrado no log:
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]
então parece que a pesquisa está acontecendo corretamente e, ainda assim, apenas um despacho acontece em vez de dois.
Responder1
Ele ocorreu quando e somente ao usar o formulário "@otherdomain", entãopoderia ser contornado:
- migrando do
table/select_field/..formulário obsoleto para especificarqueryem seumysql-*.cfarquivo e imitar no SQL o que o postfix não faz mais, ou - alterando permanentemente sua tabela para expandir esses aliases para o
user@domainformulário completo.
Ambas as soluções alternativas envolveriam uma consulta contendo algo como CASE WHEN destination LIKE "@%" THEN SUBSTR(source,1,INSTR(source,"@"))||destination ELSE destination ENDpermitir que o SQL apenas concatenasse a caixa de correio de origem se a pesquisa começar com @.
Considere cuidadosamente o que deve acontecer com extensões de endereço como user+extensions@onedomain, se você as estiver usando!
Ao procurar por possíveis razões para a mudança de comportamento, me deparei com algum retrabalho de citação/sem aspas do rfc822 quepoderiaser relevante, CHANGELOG menciona:
propagar corretamente uma extensão de endereço
de "aa bb+ext"@example.com para "cc dd+ext"@other.example
Embora se possa igualmente argumentar que todo orecurso que só funciona quando executado na primeira entrada em uma lista de endereçoscoisa é um bug em primeiro lugar. Essa etapa de pós-processamento deve ser aplicada a todos os elementos do conjunto de resultados sem qualquer possível ambiguidade entre caixa de correio/extensão/delimitador.
Consegui replicar essa confusão de tipo lista/caixa de correio no Postfix 3.4.13 (conforme distribuído pelo Ubuntu) usando e query, table/select_field/..com ou semmapa proxye com resultado de várias linhas ou resultado único separado por vírgula. Você pode conseguir trabalhar as seguintes etapas quase funcionais em um reprodutor funcional para relatar o upstream. Obviamenteexecute essas etapas apenas em uma caixa de teste.
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