Puncte:-1

Cum se trimite un e-mail cu openssl și Microsoft Exchange Online?

drapel vn

Cu Microsoft dezactivează autentificarea de bază în Exchange Online, mi-am propus să adaug suport pentru autentificare modernă în aplicația noastră. Aplicația noastră trimite alerte de bază prin e-mail. În prezent, folosim autentificarea de bază SMTP sau releul deschis pentru aceasta, dar Modern Auth ar fi un plus bun.

Pentru a înțelege pe deplin procesul, aș dori să parcurg manual întregul proces de e-mail. Am un chiriaș de dezvoltare la Microsoft, în care am înregistrat aplicația noastră. Nu am probleme în achiziționarea simbolului Oauth cu un domeniu de e-mail. Este comunicarea cu serverul SMTP prin care nu pot ajunge.

Deoarece comunicarea trebuie criptată, folosesc openssl (în loc de telnet). Mă conectez la server cu această comandă:

openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp

Există ceva feedback în legătură cu negocierea SSL și apoi serverul răspunde cu:

250 SMTPUTF8

În acel moment, cred că ar trebui să folosesc comanda EHLO. Totuşi, după

EHLO

Răspunsul este simplu (Serverul se modifică la fiecare încercare)

' [AM4PR0101CA0056.eurprd01.prod.exchangelabs.com] 

În acest moment nu sunt sigur ce să fac. Cred că poate fi necesar să inserați un domeniu după comanda ehlo (pentru a identifica chiriașul online Microsoft la care să vă conectați?). Cu toate acestea, indiferent de domeniul pe care l-am inserat, răspunsul este întotdeauna:

501 5.5.4 Nume de domeniu nevalid [AM4PR0101CA0056.eurprd01.prod.exchangelabs.com]

Poate cineva să explice cum să inițiezi comunicații cu un chiriaș Microsoft Exchange Online prin OpenSSL? Ce pun dupa EHLO? Mă conectez la adresa corectă? Încerc doar să ajung la un punct în care pot lansa o comandă AUTH XOAUTH2 pentru a mă autentifica pe chiriașul meu.

Am reușit să fac întregul proces pe serverul smtp al Gmail (smtp.gmail.com). Acolo, nu contează ce adăugați după comanda ehlo, după ce o dați, veți fi întâmpinat și puteți continua să vă autentificați cu diverse comenzi AUTH.

Puncte:0
drapel us
Rob

The EHLO este un succesor „avansat” al celui mai vechi salut și are scopul de a prezenta clientul dvs. SMTP. Atat de asemanator cu a spune "Bună! Sunt Rob, mă bucur să te cunosc." trebuie să furnizați propriul nume de gazdă după EHLO.

RFC 5312

Sintaxă:

„EHLO” „(spațiu)” „(Domeniu/adresă-literal)” „CRLF”

Numele de domeniu dat în comanda EHLO TREBUIE să fie unul principal nume gazdă (un nume de domeniu care se rezolvă la o adresă RR) sau, dacă gazda nu are nume, o adresă literală, așa cum este descris în Secțiunea 4.1.3 și discutat în continuare în discuția EHLO despre Secțiunea 4.1.4.

Unele implementări de server SMTP sunt mai stricte decât altele în ceea ce privește solicitarea ca protocolul SMTP să fie implementat corect de către clienții care se conectează. Rețineți că o implementare proastă a SMTP va crește de obicei (dramatic) scorul dvs. de spam.

drapel vn
Ok, deci am folosit un serviciu precum http://www.whatismyhostname.com/ pentru a-mi determina numele de gazdă. smtp.office365.com nu acceptă acest lucru. RFC spune în 4.1.3 că, alternativ, poate fi folosită o adresă literală (adresă IP) între paranteze drepte. Nici nu merge. Funcționează deloc asta pentru tine? Dacă aveți OpenSSL, acesta este un test foarte ușor.
Puncte:0
drapel vn

Problema mea a fost în comanda inițială:

openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp

Și în special steag-ul -crlf - fără el aș putea introduce orice după EHLO și totuși să fiu întâmpinat de serverul SMTP și să merg la AUTH.

Steagul pare să facă ceva cu sfârșiturile de linie despre care acest server SMTP este deosebit de pretențios. Deci această comandă funcționează pentru mine:

openssl s_client -connect smtp.office365.com:587 -starttls smtp

Am citit și alte surse care menționează adăugarea acestui steag pentru a rezolva problemele, pentru mine eliminarea lui a făcut truc. Recomand oricui are aceeași problemă să le încerce pe ambele.

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.