înregistrare Logare
Puncte:1
Jim At Your Service avatar Server

după actualizarea postfix 3.5.6, hărțile alias virtuale către mai mulți destinatari sunt tratate ca nume unice care conțin o virgulă

drapel de
Jim At Your Service

Tocmai am făcut upgrade la debian bullseye postfix 3.5.6 de la debian wheezy postfix 2.9.6.

Folosim hărți de alias virtuale pentru mai mulți destinatari, cum ar fi acesta:

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

Prin urmare, e-mailurile trimise la [email protected] sunt redirecționate către ambele [email protected] și la [email protected]. Funcționează corect de ani de zile.

Am învățat anterior de la http://www.postfix.org/virtual.5.html acea ordinea mai multor destinatari este importantă. „Când rezultatul are forma @otherdomain, rezultatul devine același utilizator din alt domeniu. Acest lucru funcționează numai pentru prima adresă dintr-un rezultat de căutare cu mai multe adrese.” Așa că punem pe primul loc caracterul joker @ destinatar.

După actualizarea postfix, smtpd pare să încerce să redirecționeze către a un singur destinatar „[email protected],jim”@space-port-pros.com.

Deoarece utilizatorul nu există, această e-mail este trimisă la catchall.

Iată câteva rezultate din mail.log:

Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: conectați-vă la subsistemul privat/proxymap
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: trimiteți cererea attr = căutare
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: trimiteți tabelul attr = mysql:/etc/postfix/mysql-virtual_forwardings.cf
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: trimiteți steaguri attr = 540736
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: trimiteți cheia attr = [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]: nume atribut de intrare: stare
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: valoarea atributului de intrare: 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]: nume atribut de intrare: valoare
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: valoarea atributului de intrare: @theidsp-network.inter-realm.net,[email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: atribut dorit: (terminator de listă)
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: numele atributului de intrare: (end)
14 aprilie 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
_cerere): [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, întârziere=0,06, întârzieri=0,01/0,02/0,01/0,02, dsn=2,0,0, stare=trimis (250 2,00) Ok: în coadă ca 5F628
A882)

Iată fragmente dintr-un jurnal din iunie care arată că înainte a avut ca rezultat două linii distincte cu status=sent, una prin transport smtp la [email protected] și una prin transport lmtp-g la jimays@theidsp-network .inter-realm.net.

20 iunie 06:30:58 mail7-057 sslmx/smtpd[28956]: conectați-vă de la mail7-055.idsp56.net[192.168.56.55]
20 iunie 06:30:58 mail7-057 sslmx/smtpd[28956]: Conexiune TLS anonimă stabilită de la mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 cu cifră AECDH-AES256-S25 (biți 256-S25 )
20 iunie 06:30:58 mail7-057 sslmx/smtpd[28956]: B91A42BE4: client=mail7-055.idsp56.net[192.168.56.55]
20 iunie 06:30:58 mail7-057 cleanup-srs/cleanup[28963]: B91A42BE4: message-id=<[email protected]>
20 iunie 06:30:58 mail7-057 postfix/qmgr[19327]: B91A42BE4: from=<SRS0=Z5tX=LO=connect.match.com=bounces-MA-1-858-ea0868c4-498f-401a-b6f [email protected]>, size=47942, nrcpt=2 (coada activă)
20 iunie 06:30:58 mail7-057 sslmx/smtpd[28956]: deconectați-vă de la mail7-055.idsp56.net[192.168.56.55]
20 iunie 06:30:58 mail7-057 postfix/smtp[28966]: Conexiune TLS anonimă stabilită la mail7-052.idsp56.net[192.168.56.52]:52025: TLSv1.2 cu cifră AECDH-AESHA (2556-SHA256-SHA) 256 de biți)
20 iunie 06:30:58 mail7-057 lmtp-g/lmtp[28965]: Conexiune TLS de încredere stabilită la lmtp7-g.inter-dimensional-space-port.net[216.184.19.228]:64007: TLSv1 cu cifră AES256- SHA (256/256 biți)
20 iunie 06:30:58 mail7-057 postfix/smtp[28966]: B91A42BE4: to=<[email protected]>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, întârziere=0,16, întârzieri=0,04/0,02/0,02/0,08, dsn=2,0,0, stare=trimis (250 2.0.0 Ok: în coadă ca C66855B94)
20 iunie 06:30:59 mail7-057 sslmx/smtpd[28956]: conectați-vă de la mail7-055.idsp56.net[192.168.56.55]
20 iunie 06:30:59 mail7-057 sslmx/smtpd[28956]: Conexiune TLS anonimă stabilită de la mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 cu cifră AECDH-AES256-S25 (biți 256-S25) )
20 iunie 06:30:59 mail7-057 sslmx/smtpd[28956]: 9D1D12CA5: client=mail7-055.idsp56.net[192.168.56.55]
20 iunie 06:30:59 mail7-057 cleanup-srs/cleanup[28963]: 9D1D12CA5: message-id=<[email protected]>
20 iunie 06:30:59 mail7-057 postfix/qmgr[19327]: 9D1D12CA5: from=<SRS0=Z5tX=LO=connect.match.com=bounces-MA-1-858-ea0868c4-498f-401a-b6f [email protected]>, size=50423, nrcpt=1 (coada activă)
20 iunie 06:30:59 mail7-057 sslmx/smtpd[28956]: deconectați-vă de la mail7-055.idsp56.net[192.168.56.55]
20 iunie 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, întârziere=8,9, întârzieri=0,04/0,02/0,12/8,7, dsn=2,0,0, stare=trimis (250 Ok)
20 iunie 06:31:07 mail7-057 postfix/qmgr[19327]: B91A42BE4: eliminat

The http://www.postfix.org/COMPATIBILITY_README.html nu a menționat nimic specific despre o schimbare de comportament în hărțile alias virtuale.

mysql-virtual_forwardings.cf este într-un format standard creat de ISPConfig.

utilizator = ispconfig
parola = redactat
dbname = idsp_mail7_062
table = mail_forwarding
select_field = destinație
unde_câmp = sursă
condiții_addiționale = și active = „y” și server_id = 81
gazde = 192.168.56.121

Piesa relevantă din main.cf care invocă fișierul este:

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

Tabelul virtual_forwardings arată astfel:

MariaDB [idsp_mail7_057]> selectează * din mail_forwarding unde source='[email protected]';
+---------------+------------+-------------+------ ---------+----------------+----------------+------ -----+--------------------+----------------------- ----------------------------------+---------+---- ----+
| forwarding_id | sys_userid | sys_groupid | sys_perm_user | sys_perm_group | sys_perm_other | server_id | sursa | destinație | tip | activ |
+---------------+------------+-------------+------ ---------+----------------+----------------+------ -----+--------------------+----------------------- ----------------------------------+---------+---- ----+
| 201 | 2 | 2 | riud | riud | | 69 | [email protected] | @theidsp-network.inter-realm.net,[email protected] | înainte | y |
+---------------+------------+-------------+------ ---------+----------------+----------------+------ -----+--------------------+----------------------- ----------------------------------+---------+---- ----+
1 rând în set (0,001 sec)

S-a crescut înregistrarea în jurnal la smtpd -v -v și acest lucru se arată în jurnal:

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
_cerere): [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]

deci se pare că căutarea are loc corect, și apoi se întâmplă totuși o singură expediere în loc de două.

62
0 + 0
Jim At Your Service avatar
drapel de
Jim At Your Service
Bună @anx. Mă întreb dacă sugerezi că există o eroare în postfix smtpd. Avem multe înregistrări care utilizează acest format ATotherdomain,somewhereATsomespecific.com, pentru a le redirecționa pe ambele către ATotherdomain plus la o anumită adresă de e-mail. Mă întreb dacă vedeți o soluție specifică pentru aceasta.
0
Răspunde
Jim At Your Service avatar
drapel de
Jim At Your Service
@anx. Am confirmat că lucrurile funcționează corect dacă înlocuiesc intrarea cu jimaysATtheidsp-network.inter-realm.net,jimATspace-port-pros.com, așa că, într-adevăr, iau în considerare ideea dvs. de a schimba toate intrările noastre ca o soluție.Dar hmm, ce s-a întâmplat de fapt aici?
1
Răspunde
anx avatar
drapel fr
anx
Deși nu am săpat în detalii, cred că chiar și orice documentație percepută sau reală *ambiguitate* despre modul în care sunt tratate listele de adrese necotate merită să fie considerată o eroare. Vă rugăm să raportați acest lucru în amonte, este posibil să puteți crea un reproductor mai scurt folosind pașii (sqlite, nu mysql) pe care i-am descris mai jos.
0
Răspunde
Puncte:0
anx avatar Server
drapel fr
anx

S-a întâlnit cu el când și numai când se folosește formularul „@otherdomain”, deci ar putea fi rezolvat:

  1. prin migrarea de la depreciat tabel/select_field/.. formular pentru a specifica interogare în dumneavoastră mysql-*.cf fișier și imită în SQL ceea ce postfix nu mai face sau
  2. prin schimbarea permanentă a tabelului pentru a extinde acele alias-uri la maximum utilizator@domeniu formă.

Ambele soluții ar implica o interogare care conține ceva de genul CASE WHEN destinație LIKE "@%" THEN SUBSTR(sursă,1,INSTR(sursă,"@"))||destinație ELSE destinație END pentru a lăsa SQL să concateneze cutia poștală sursă dacă căutarea începe cu @. Luați în considerare cu atenție ce ar trebui să se întâmple cu extensii de tipul utilizator+extensii@onedomain, dacă le folosiți!

Când am căutat posibile motive pentru comportamentul schimbat, am dat peste o reluare rfc822 citată/unquote care Mai fi relevant, CHANGELOG menționează:

propaga corect o extensie de adresă

de la „aa bb+ext”@example.com la „cc dd+ext”@other.example

Deși s-ar putea argumenta în egală măsură că întregul caracteristică care funcționează numai atunci când este executată la prima intrare dintr-o listă de adrese chestia este o eroare în primul rând. Un astfel de pas de post-procesare ar trebui aplicat tuturor elementelor setului de rezultate fără nicio ambiguitate posibilă între cutia poștală/extensie/delimitator.

Am reușit să reproduc acea confuzie de tip listă/cutie poștală în Postfix 3.4.13 (așa cum este distribuit de Ubuntu) folosind fie interogare și tabel/select_field/.., cu sau fără proxymap, și fie cu rezultat pe mai multe rânduri, fie cu un singur rezultat separat prin virgulă. Este posibil să puteți lucra următorii pași aproape de lucru într-un reproductor funcțional pentru a raporta în amonte. Evident rulați acești pași doar pe o cutie de testare.

ieșire 1 # PIERDERE DE DATE! RULĂȚI NUMAI PE MASINA VIRTUALĂ PENTRU TESTARE!
postconf virtual_transport=eroare
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
# trimite mail de testare (smtp nu setuid, deoarece smtp produce jurnale mai frumoase)
printf %b 'import smtplib;\nsmtplib.SMTP("::1").sendmail("","[email protected]", "")' | python3
printf %b 'import smtplib;\nsmtplib.SMTP("::1").sendmail("","[email protected]", "")' | python3
# verifica jurnalele
0 + 0
Jim At Your Service avatar
drapel de
Jim At Your Service
Răspunsul dvs. este complet și util și a fost absorbit de recunoștință, va ajunge în amonte în timp util cu o referire la aici. Soluția dvs. de soluționare este cea mai utilă mie și echipei noastre în acest moment, deoarece arată o cale înainte pentru ca e-mailul să curgă din nou, trebuie doar să schimbați ATdomain pentru a fi un userATdomain complet. Putem rula o actualizare SQL pentru a face asta dintr-o dată. Apoi tot ce trebuie să facem este să trecem prin căsuța poștală și să redistribuim toate acele e-mailuri din ultimele două săptămâni... Mulțumesc. Acesta este primul meu post și mă întreb cum să marchez rezolvat.
0
Răspunde
Jim At Your Service avatar
drapel de
Jim At Your Service
Serverul nostru de e-mail este acum remediat datorită @anx și lib_mysqludf_preg: `update mail_forwarding set destination=concat(regexp_replace(source,'@.*$',''),destination) unde destinație ca '@%';`
1
Răspunde
Jim At Your Service avatar
drapel de
Jim At Your Service
... am încercat să dau clic pe bifa, am nevoie de 15 puncte de reputație... răspunsul dvs. cu siguranță a rezolvat problema noastră, mulțumesc
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.