Puncte:0

Care este semnificația parametrului bounce="false" într-un răspuns 553 de la un MTA receptor?

drapel in

Aceasta este o scurtă întrebare tehnică specifică despre un schimb între două MTA-uri. Este derivat din această întrebare în Superuser, care este mai larg și conține câteva dezvăluiri despre asistența tehnică de la anumiți furnizori de e-mail. Mai jos este o versiune foarte igienizată a intrărilor de fișiere jurnal luate din jurnalele unui MTA de ieșire, unde 1.2.3.4 este adresa IP a MTA-ului de ieșire și 5.6.7.8 este adresa IP a MTA-ului receptor. Expeditorul inițial nu a primit niciun mesaj de respingere, iar e-mailul nu a fost livrat niciodată destinatarului (nici căsuța de e-mail, nici dosarul de spam, nici coșul de gunoi). Aș dori să înțeleg sensul bounce="fals" parametrul în răspunsul 553 de la MTA-ul receptor. (Rețineți că intrările sunt ordonate de la cel mai nou la cel mai vechi, așa cum se arată în marcajele de timp). Mulțumiri!

20210812 09:29:10.177 core sid="id1" id="id1id2"
    ip="1.2.3.4" action="PERMERR" dstmta="5.6.7.8" age="61" code="553"
    motiv="553 5.3.0 198.71.225.36 Mesajul dvs. a fost respins pentru posibil spam/virus
    conținut. Vă rugăm să cereți furnizorului dvs. de e-mail să acceseze http://emailadmin.registeredsite.com
    pentru rezolvare.\r\n" account="[email protected]""
    fwd="0" bounce="false" mailfrom="[email protected]" fromdomain="sending-example.com"
    recipient_list="[email protected]" todomain="receiving-example.com"
    subject="Vești triste" subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""

20210812 09:28:09.658 core sid="id1" id="id1id2"
    ip="1.2.3.4" action="ACCEPT" motiv="CLEAN" account="[email protected]"
    fwd="0" mailfrom="[email protected]" fromdomain="trimitere-example.com"
    recipient_list="[email protected]" todomain="receiving-example.com" subject="Vești triste"
    subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""

Editare 1:

Acest lucru nu răspunde cu adevărat la întrebarea așa cum a fost adresată, dar în apelurile de asistență ulterioare cu cei doi furnizori de e-mail implicați, părea să existe un anumit acord că MTA-ul de primire care a dat răspunsul 553 MTA-ului expeditor a fost cel care ar fi trebuit să trimită un trimite mesajul către expeditorul plicului. Cu toate acestea, un agent al MTA care primește mi-a subliniat astăzi că răspunsul lor 553 în sine conține o a treia adresă IP: 198.71.225.36. Și că adresa respectivă este cea de care se plânge și, de fapt, este pe lista neagră dacă verificați la adresa URL conținută în mesaj. În tot acest timp nu observasem acea adresă ca fiind relevantă (sau chiar o adresă, ar fi putut fi numere de secțiune precum 5.3.0 sau ceva de genul). 1.2.3.4 a fost adresa IP pentru serverul identificat prin intrarea MX din fișierul de zonă pentru domeniul de trimitere, așa că am presupus că este cea care trebuie să fi fost pe lista neagră! Încă nu am primit o explicație pentru "bounce="fals"' sau ce server l-a generat.

Michael Hampton avatar
drapel cz
Trebuie să identificați software-ul MTA în uz. Nu seamănă cu nimic întâlnit în mod obișnuit în rețea.
drapel in
@Michael Hampton MTA care trimite este Goddaddy, MTA Network Solutions care primește. Cred că amândoi se ocupă de multe e-mailuri. Așa că pare puțin surprinzător că jurnalul arată „neobișnuit”. Intrările de jurnal au venit de la agenții de asistență tehnică godaddy care le-au extras din jurnalele lor de ieșire ale serverului. Fiecare intrare a fost o singură linie, doar am igienizat adresele IP și domeniile și le-am împachetat în mai multe linii cu indentare pentru a posta aici. 553 cu parametrul 'bounce="false"' a venit de la serverul netsol. Adresa IP a acelui server este deținută de Cloudflare. nu netsol, ceea ce mi se pare ciudat.
Michael Hampton avatar
drapel cz
Acestea sunt ambele companii, nu MTA-uri. Dacă GoDaddy a scris un MTA personalizat, atunci ar trebui să-i întrebați ce înseamnă.
drapel in
Bine, pot face asta. Tocmai reacționam la „nevăzut în mod obișnuit în rețea”, în sensul că godaddy și netsol sunt ambii furnizori destul de obișnuiți. Dar, în timp ce parametrul 'bounce="false"' apare în jurnalul de la godaddy, este de fapt în răspunsul 553 de la netsol. Pot să-i întreb și pe ei, dar nu m-aș aștepta la un răspuns semnificativ. În cele din urmă, am vorbit cu un supervizor netsol aseară, care a promis să rămână la curent și să-mi dea o actualizare mâine. Îl voi întreba despre MTA-ul lor și îl voi posta aici. Mulțumiri!
Michael Hampton avatar
drapel cz
Netsol? Credeam că ai spus că aceste jurnalele provin de la GoDaddy?
drapel in
Da, intrările de jurnal au venit de la godaddy, înregistrând o conversație pe care serverul lor de ieșire, 1.2.3.4, a avut-o cu serverul de intrare netsol, 5.6.7.8. Am crezut că lucrul interesant a fost parametrul bounce="false", care a venit de la MTA-ul de recepție al netsol (a cărui adresă IP aparține de fapt Cloudflare, conform ARIN).Nu ar trebui să conteze cine a înregistrat intrările de jurnal, cu excepția cazului în care credeți că Godaddy a fabricat schimbul :-) Până acum, nu am reușit să obțin ora din zi de la netsol, darămite ce software MTA folosesc.
Michael Hampton avatar
drapel cz
De ce spui că bounce=false a venit de la netsol? În mod clar a venit de la GoDaddy.
drapel in
Nu. Acest parametru se află pe răspunsul 553, care conține, de asemenea, linkul pentru a verifica de ce a fost detectat ca spam și acel link merge către un site netsol, unde poți introduce o adresă IP și îți spun dacă sunt sau nu. blocând-o. Am făcut asta de multe ori și mi-a răspuns întotdeauna că adresa IP godaddy nu este blocată. Verificați, de asemenea, marcajele de timp, 553 de la netsol este cu aproximativ o jumătate de secundă mai târziu decât a doua intrare care spune că mesajul este curat (godaddy verifică mesajul de ieșire).
Michael Hampton avatar
drapel cz
Cred că ați citit greșit intrarea în jurnal. `bounce=false` nu face parte din răspunsul 553 netsol. Aceasta se termină la `pentru rezoluție.\r\n"`
drapel in
Ahh, am văzut \r\n, dar nu mi-am dat seama că a marcat sfârșitul răspunsului. M-am gândit că fiecare mesaj va începe cu un marcaj de timp. Bănuiesc că de aceea îți plătesc mulți bani! Deci cred că acum pot să mă întorc la Goddaddy și să mă plâng de faptul că nu au emis o respingere? Sau ar fi trebuit netsol să emită o respingere expeditorului cu răspunsul 553 în loc să-i spună doar MTA-ului lui Godaddy despre asta? Mesajul despre a cere furnizorului dvs. de e-mail să verifice site-ul înregistrat este destinat în mod clar utilizatorului final, mai degrabă decât MTA-ului care trimite.
Michael Hampton avatar
drapel cz
Ei bine, înainte de a țipa prea tare, ar trebui pur și simplu să-i întrebi ce înseamnă `bounce=false`.
drapel in
Bine, voi face asta și voi raporta. Totuși, nu va fi decât mai târziu, deoarece am acoperișori care lucrează acum deasupra mea și nu pot vorbi la telefon (sau să mă gândesc). Acoperiș nou după 43 de ani, am câștigat banii...
drapel in
L-am contactat pe Dumnezeu. Ei folosesc exim. Agentul a spus că va verifica setările de configurare pentru a vedea dacă ar putea face ceva pentru a-l face să revină la expeditor și a venit gol. El a fost de acord că, în cazul în care netsol dă 553 cu un mesaj destinat utilizatorului final, atunci ei ar trebui să fie cei care trimit sărirea. Am descărcat sursa exim, dar în timp ce „găsește | xargs egrep' a găsit o mulțime de mențiuni de spam și respingere. Nu am găsit nimic care să pregătească un mesaj cu acel parametru în el.Așteptăm să ne contacteze supervizorul netsol. Mulțumesc foarte mult pentru ajutor!
Michael Hampton avatar
drapel cz
Ei bine, asta este și mai ciudat, pentru că [jurnalele exim nu arată deloc așa](https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html). Supa se ingroasa...

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.