înregistrare Logare
Puncte:1
Sumak avatar Server

SMTP 550 5.1.1, dar căsuța poștală există

drapel ru
Sumak

Creez o cutie poștală pe serverul nostru Postfix. Avem un script care sincronizează LDAP-ul nostru cu Webmail (~RoundCube), apoi trebuie să executăm următoarea comandă pe serverul Postfix:

echo -e "test@domain.tld\tOK" >> /etc/postfix/virtual_mailbox
echo -e "test@domain.tld\talias.test@domain.tld" >> /etc/postfix/virtual_alias # dacă vrem un alias
postmap /etc/postfix/virtual_mailbox && postmap /etc/postfix/virtual_alias
/etc/init.d/postfix reîncărcare

Această procedură a funcționat până săptămâna trecută și nu putem explica/rezolva problema.

Trimiterea unui e-mail de probă prin Webmail către căsuța poștală nou creată returnează:

<test@domain.tld>: gazda 127.0.0.1[127.0.0.1] a spus: 550-Mailbox necunoscut. Fie
    nu există nicio cutie poștală asociată cu acest nume de 550 sau nu aveți
    autorizație pentru a-l vedea. 550 5.1.1 Utilizator necunoscut (ca răspuns la RCPT TO
    comanda)

Cu toate acestea, Postfix răspunde 250 2.1.0 Ok la RCP TO:<test@domain.tld> comanda:

$ nc our.mail.server.tld 25
220 our.mail.server.tld ESMTP Postfix (CentOS)
domeniul HELO.tld
250 our.mail.server.tld
POSTA DE LA:<>
250 2.1.0 Ok
RCPT TO:<test@domain.tld>
250 2.1.0 Ok
DATE
Subiect: testare
e-mail de testare
.
250 2.0.0 Ok: în coadă ca 7E8B043

Dar jurnalul de corespondență indică a 550 5.1.1 Utilizator necunoscut... (jurnal anonimizat)

# editat după recomandarea Nikita Kipriyanov 
8 iulie 15:07:36 srv postfix/smtp[30469]: > 127.0.0.1[127.0.0.1]:10024: RCPT TO:<test@domain.tld> ORCPT=rfc822;test@domain.tld
8 iulie 15:07:36 srv postfix/smtp[30469]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.5 Destinatar <test@domain.tld> OK
8 iulie 15:07:37 srv postfix/smtpd[30492]: < localhost[127.0.0.1]: RCPT TO:<test@domain.tld> ORCPT=rfc822;test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: extract_addr: input: <test@domain.tld>
8 iulie 15:07:37 srv postfix/smtpd[30492]: smtpd_check_addr: addr=test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: trimiteți adresa attr = test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: valoarea atributului de intrare: test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: rewrite_clnt: local: test@domain.tld -> test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: trimiteți adresa attr = test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: valoarea atributului de intrare: test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: resolve_clnt: `' -> `test@domain.tld' -> transp=`lmtp' host=`127.0.0.1:24' rcpt=`test@domain .tld' flags= class=virtual
8 iulie 15:07:37 srv postfix/smtpd[30492]: ctable_locate: instalați cheia de intrare test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: extract_addr: în: <test@domain.tld>, rezultat: test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: ctable_locate: lăsați cheia de intrare existentă test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: milter_macro_lookup: rezultat „test@domain.tld”
8 iulie 15:07:37 srv postfix/smtpd[30492]: ctable_locate: lăsați cheia de intrare existentă test@domain.tld
8 iulie 15:07:37 srv postfix/smtpd[30492]: ctable_locate: lăsați cheia de intrare existentă test@domain.tld
Jul 8 15:07:37 srv postfix/smtpd[30492]: milter8_rcpt_event: milter inet:127.0.0.1:8891: rcpt <test@domain.tld> ORCPT=rfc822;test@domain.tld
Jul 8 15:07:37 srv postfix/smtpd[30492]: eveniment: SMFIC_RCPT; macrocomenzi: {rcpt_addr}=test@domain.tld {rcpt_host}=127.0.0.1:24 {rcpt_mailer}=lmtp
8 iulie 15:07:37 srv postfix/lmtp[30505]: > 127.0.0.1[127.0.0.1]:24: RCPT TO:<test@domain.tld>
8 iulie 15:07:37 srv cyrus/lmtp[18927]: verify_user(user.test) failed: Cutia poștală nu există
8 iulie 15:07:37 srv postfix/lmtp[30505]: trimiteți attr original_recipient = test@domain.tld
8 iulie 15:07:37 srv postfix/lmtp[30505]: trimiteți attr destinatar = test@domain.tld
8 iulie 15:07:37 srv postfix/lmtp[30505]: trimiteți attr dsn_orig_rcpt = rfc822;test@domain.tld
Jul 8 15:07:37 srv amavis[23265]: (23265-17) A trecut BAD-HEADER-7 {RelayedInternal}, MYNETS LOCAL [172.16.10.39]:2828 <> -> <test@domain.tld>, mail_id : nTFlKNl0Vr0b, Afișări: 5.677, dimensiune: 300, în coadă: C7DB445, 1476 ms
8 iulie 15:07:37 srv postfix/smtp[30469]: 73B0143: to=<test@domain.tld>, relay=127.0.0.1[127.0.0.1]:10024, delay=49, delays=48/0/ 0/1.5, dsn=2.0.0, stare=trimis (250 2.0.0 de la MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: în coadă ca C7DB445)
8 iulie 15:07:37 srv postfix/lmtp[30505]: C7DB445: to=<test@domain.tld>, relay=127.0.0.1[127.0.0.1]:24, delay=0.11, delays=0.09/0/ 0/0.03, dsn=5.1.1, status=bounced (gazda 127.0.0.1[127.0.0.1] a spus: 550-Mailbox necunoscut. Fie nu există nicio cutie poștală asociată cu acest nume de 550, fie nu aveți autorizație să o vedeți 550 5.1.1 Utilizator necunoscut (ca răspuns la comanda RCPT TO))

Ai idee despre acest comportament? De ce RCPT TO se intoarce 250 2.1.5 Ok cu netcat, dar până la urmă rămâne blocat cu a 550 5.1.1 Utilizator necunoscut ?

# =================================================== ==========================
# tip de serviciu private unpriv chroot wakeup maxproc command + args
# (da) (da) (da) (niciodată) (100)
# =================================================== ==========================
smtp inet n - n - - smtpd
depunerea inet n - n - - smtpd
  -o smtpd_tls_security_level=criptare
  -o smtpd_sasl_auth_enable=da
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINARE
smtps inet n - n - - smtpd
  -o smtpd_tls_wrappermode=da
  -o smtpd_sasl_auth_enable=da
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINARE
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
curatare unix n - n - 0 curatare
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rescrie unix - - n - - trivial-rescriere
bounce unix - - n - 0 bounce
amână unix - - n - 0 săritură
trace unix - - n - 0 săritură
verifica unix - - n - 1 verifica
spălați Unix n - n 1000? 0 culoare
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
# Când transmiteți e-mailul ca MX de rezervă, dezactivați fallback_relay pentru a evita buclele MX
releu unix - - n - - smtp
        -o smtp_fallback_relay=
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
eroare unix - - n - - eroare
reîncercați Unix - - n - - eroare
arunca unix - - n - - arunca
unix local - n n - - local
unix virtual - n n - - virtual
lmtp unix - - n - - lmtp
nicovală unix - - n - 1 nicovală
scache unix - - n - 1 scache

smtp-amavis unix - - n - 8 smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=da
    -o disable_dns_lookups=da

127.0.0.1:10025 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o hărți_releu_destinatar=
    -o smtpd_restriction_classes=
    -o smtpd_delay_reject=nu
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8,<other_valids_networks>
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
311
1 + 7
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Puteți adăuga temporar 127.0.0.1 în `debug_peer_list`, pentru care demonii Postfix se vor executa cu un nivel de jurnal ridicat.În jurnalul (foarte extins), va explica modul în care interpretează fiecare directivă de configurare și acest lucru ar trebui să ofere un indiciu unde eșuează. Deocamdată, sunt sigur cum să depanez asta, cu condiția să utilizați o configurație care a fost „obișnuită să funcționeze” anterior.
2
Răspunde
Sumak avatar
drapel ru
Sumak
Vă mulțumim pentru feedback-ul dumneavoastră. Am făcut asta și mi-am editat răspunsul. Ar putea fi legat de modificările din înregistrările noastre DNS? Suntem pe cale să migram serverul nostru de e-mail și este posibil ca furnizorii de servicii cu care lucrăm să fi modificat deja DNS-ul.
0
Răspunde
Michael Hampton avatar
drapel cz
Michael Hampton
Ei bine, asta e ciudat. Vă rugăm să postați și fișierul `main.cf`.
1
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Uau, am observat ceva. Conform jurnalului dvs., 73B0143 este primit cu succes prin SMTP la portul 10025 ca C7DB445, dar imediat acel lucru încearcă să-l injecteze prin LMTP în portul 24, unde este respins. Care sunt lucrurile care ascultă la porturile 10025 (care acceptă prin smtp și relee prin lmtp) și 24 (care respinge prin lmtp)?
2
Răspunde
Sumak avatar
drapel ru
Sumak
Este neobișnuit? Mă tem că nu avem suficiente cunoștințe pentru a interpreta acest fapt. `smtpd` ascultă portul 10025 (cu opțiunile menționate la sfârșitul lui `master.cf`) și `[khelper]` portul 24.
0
Răspunde
anx avatar
drapel fr
anx
Menționați migrațiile în curs.. ar fi putut cineva să plaseze un server LDAP gol pe domeniul de pe care Cyrus încă își preia direct utilizatorii?
0
Răspunde
anx avatar
drapel fr
anx
`[khelper]` sună mai mult ca un fir de nucleu și mai puțin ca un serviciu LMTP. Căutați configurația *Cyrus*, care este mai probabil ceea ce ascultă pe `24/tcp`
0
Răspunde
Puncte:0
anx avatar Server
drapel fr
anx

Postfix returnează pur și simplu ceea ce i s-a spus de serviciul LMTP pe care a încercat să predea corespondența pentru livrare. Dacă aliasul extins este corect, trebuie să verificați acea serviciu, nu (doar) Postfix.

Multe lucruri ar fi putut duce la acest scenariu, dar este destul de clar că lista de utilizatori/alias de Postfix nu mai este sincronizată cu utilizatorul serverului Postfix trece mailto (ocolul prin Amavis complică jurnalele, dar nu pare să fie problema).

Următorul pas de diagnosticare: comparați lista de utilizatori disponibilă cu MDA (Cyrus IMAPd, după aspectul mesajului de eroare) la rezultatul real al mapărilor dvs. virtuale postfix.

Interogați hărțile postfix cu aceste comenzi:

postmap -v -v -q test@domain.tld hash:/etc/postfix/virtual_mailbox
postmap -v -v -q test@domain.tld hash:/etc/postfix/virtual_alias

Interogarea astfel este mai bună decât să ai încredere că ai executat comanda corect, deoarece duplicatele și greșelile de scriere sunt mai evidente atunci. eu gândi configurarea dvs. în general are ca rezultat numai unu dintre cele două hărți.

Interogați lista de utilizatori a serviciului LMTP folosind informațiile pe care le veți găsi în configurația acestuia pentru a verifica existența cu adevărat a căsuței poștale. Pentru a interoga direct LDAP, utilizați ldapsearch -U .. -H ldaps://.., pentru a investiga anumite servere, utilizați utilitățile furnizate: pentru Porumbar, utilizare utilizator doveadm .. - pentru Cyrus utilizare cyrusadm info [nume], ..

Luați în considerare, de asemenea, moduri de eșec, cum ar fi serverul LDAP în care vă păstrați lista de utilizatori, nu a fost accesibil temporar sau permanent de către un server sau un script de întreținere menit să preia acele date.

Ați fi putut ușura acest lucru și puteți ușura în continuare depanarea ulterioară prin adăugarea adecvată syslog_name opțiuni în dvs maestru.cf - în acest fel puteți spune mai ușor care dintre serviciile dvs. (aparent multiple similare) a înregistrat ce linii.

depunerea inet n - n - - smtpd
 -o syslog_name=postfix/submission
 -o smtpd_tls_security_level=criptare
 -o...
...
smtps inet n - n - - smtpd
 -o syslog_name=postfix/smtps
 -o smtpd_tls_wrappermode=da
 -o...
...
127.0.0.1:10025 inet n - n - - smtpd
 -o syslog_name=postfix/descriere
 -o...
0 + 0
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.