Puncte:0

Empty Email when using MS365 as a mail relay from a Python application

drapel co

We've got a very weird issue going on here.

Take this example email (raw form, sanitized):

To: [email protected]
From: Thomas Ward via TestList <[email protected]>
Subject: Test Message
Date: Wed, 4 Aug 2021 19:44:49 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------EFA1B8DAB3C4E625DD16F705"
Content-Language: en-US
Sender: [email protected]
Reply-To: Thomas Ward <teward@NOPE>
CC: Thomas Ward <teward@NOPE>
Message-ID: <162812069430.22940.8470019517074758016@listserv-server>
List-Id: TestList <[email protected]>
List-Post: <mailto:[email protected]>

--------------EFA1B8DAB3C4E625DD16F705
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Test


--------------EFA1B8DAB3C4E625DD16F705
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Test<br>
    </p>
  </body>
</html>

--------------EFA1B8DAB3C4E625DD16F705--

This is being sent via straight SMTP to a Send Connector at MS365 configured to receive and relay mail from our on-prem mail server to MS365 for retransmission to the Internet.

Except... while the email retransmits to the destination external recipients... it actually only sends the To, From, Subject, etc. but completely ignores the actual content of the message. This was replicated with direct submission of a MIMEText() test email in Python as well.

The same email, however, when directly submitted to the external mail servers where I'm receiving this (where @NOPE would be my actual domain and server), transmits and relays fine, with all content. The same thing happens as well when we transmit via an on-prem Postfix relay which goes through a Sophos appliance, which then goes directly to the recipient server.

So, it seems that routing any mail via Exchange Online in this way with an on-prem system sending mail via MS365 outright fails to function. Regardless of the message submitted.

Has anyone else got any kind of on-prem mail system(s) or solutions here which need to route via MS365, and simply is unable to without Microsoft eating the message in its entirety?

The above email was sent to the Test List from external, routed through to an on-prem Exchange server (Exchange Hybrid setup due to on-prem listservs), modified for DMARC compliance, and then retransmitted to two external addresses as a new message, same issue at recipient ends. Also same issue for internal MS365 (in-organization) recipients.

Again, delivery works fine via on-prem Postfix stuff, but not when relayed via MS365 (which clearly ACCEPTED the emails and retransmitted everything EXCEPT the actual message).

Puncte:0
drapel co

OK, deci se pare că mi-am dat seama, dar este ceva pentru care va trebui să strig la Microsoft.

Mesajele din întrebarea mea sunt textuale ce este trimis către Postfix și ce este trimis către conectorul SMTP Outlook. Diferența este, totuși, că Postfix gestionează corect mesajul și apoi îl retransmite oarecum într-un mod diferit de modul în care smtplib-ul lui Python se ocupă de transmiterea e-mailurilor. Mesaje și conținutul lor este livrat corect atunci când este predat pentru prima dată către un server Postfix pentru procesare înainte de a fi trimis prin intermediul conectorului de trimitere la MS365. Ceea ce... nu este ceea ce ne doream, deoarece nu doream să menținem niciun fel de server de e-mail real pe prem, Postfix sau altfel și am vrut doar să livrăm direct la Microsoft 365 pentru manipulare, mai degrabă decât să avem nevoie de un „salt intermediar” într-un server de mail și MTA inainte de primirea de mesaje de la clienți și conectori terminale.

De asemenea, este ciudat că Microsoft 365 este incapabil să predea corect mesajele predate direct către acesta, cu excepția cazului în care Microsoft are un format ciudat pe care vrea să se ocupe de asta. nu este Conform RFC... dar asta este o altă luptă.

Puncte:-1
drapel us

Aplicația dvs. îndeplinește următoarele cerințe? Cum să configurați un dispozitiv sau o aplicație multifuncțională pentru a trimite e-mail folosind Microsoft 365 sau Office 365

Încercați să utilizați Trimite-Mesaj sau Telnet pe serverul dvs. de e-mail pentru a testa SMTP și a vedea dacă există vreo diferență.

În plus, poate că următorul thread este util: Trimite emal stmp office 365 : mesaj gol

drapel co
Opțiunea 3 este deja în vigoare. Știm că aplicația de e-mail care trimite SMTP prin Releu către MS365 declanșează un răspuns de succes de la coada de așteptare pentru livrare, dar apoi MS365 face ceva cu mesajul și transmite un mesaj în mare parte gol. I.E. fiecare antet este păstrat, dar nicio sarcină utilă nu este retransmisă. Din câte știu, SMTP Relay nu ar avea nevoie de o licență pentru asta, dacă nu mă înșel? Avem câteva licențe Business Basic cu care ne putem juca dacă trebuie să folosim un expeditor autentificat/licențiat.
drapel co
Și în ceea ce privește firul SO, generăm deja un context MIMEText atunci când trimitem mesaje de testare prin Python - deci nu asta este problema.
Ivan_Wang avatar
drapel us
Care este rezultatul dacă vă conectați la Exchange Online PowerShell și rulați următoarele comenzi: 1. **Get-TransportConfig | fl SmtpClientAuthenticationDisabled** 2. **Get-CASMailbox | fl SmtpClientAuthenticationDisabled**. Parametrul „SmtpClientAuthenticationDisabled” este pentru a specifica dacă se dezactivează SMTP autentificat (SMTP AUTH) pentru întreaga organizație sau pentru o singură cutie poștală. Mai multe detalii despre acesta: https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps
drapel co
Nu avem o identitate de cutie poștală pentru aceasta - încercăm să trimitem alerte de la un sistem local care nu are cutie poștală prin livrare directă SMTP către destinatarii lor din partea Cloud a infrastructurii. Prima comandă returnează True, astfel încât autentificarea clientului este dezactivată. Cu toate acestea, cu conectorul la locul lui (adică MS365 este configurat să ACCEPTĂ e-mailuri fără întrebări sau autentificare de la serverul SMTP local), nu ar trebui să eșueze niciodată din cauza autentificării. Și *putem* trimite un mesaj în acest fel, iar acesta este livrat, cu excepția faptului că nu există nici un *corp* de e-mail inclus în mesajul livrat

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.