Exchange 2019 probleem.

[PFY]

Hoi,

Ben bezig me wat te verdiepen in Exchange Server 2019.
Ik heb 2 vm,s thuis ingericht, 1 AD, en een Exchange, langzamerhand werkt alles steeds beter, echter blijf met een euvel zitten dat als ik een mail verstuur vanaf owa naar het internet dat deze wel aankomt bij mijn internet mail server (mdaemon) echter deze meld
""Remote Server returned '530 5.7.0 Authentication required""


Dat is vaag, want de mail gaat dus wel netjes eruit, echter de ontvangende server meld dat hij wil dat er authenticatie wordt meegestuurd ?

ik vermoed dat ik ergens iets ben vergeten, echter wat.

Server is Windows server 2022
Exchange 2019 CU12
Alles updates staan erop.
Certificaten zijn accuraat en werkende voor de server en de sub websites.

[nelizmastr]

Stuur je naar je Mdaemon als smarthost met je Exchange Server?

Al eens SMTP auth gegevens ingevoerd in de instellingen voor de Smarthost? Doet-ie het dan wel?

Je Exchange gebruikers kunnen zich niet authentiseren bij de Mdaemon tenzij ze dezelfde authenticatie provider (AD) gebruiken.

[Voor 18% gewijzigd door nelizmastr op 27-10-2022 16:51]

[Bazvv]

Volgens mij kwestie van smart host authentication instellen op de send connector richting mdaamon.

[PFY]

nelizmastr schreef op donderdag 27 oktober 2022 @ 16:50:
Stuur je naar je Mdaemon als smarthost met je Exchange Server?

Al eens SMTP auth gegevens ingevoerd in de instellingen voor de Smarthost? Doet-ie het dan wel?

Je Exchange gebruikers kunnen zich niet authentiseren bij de Mdaemon tenzij ze dezelfde authenticatie provider (AD) gebruiken.

Probeer de exchange bak puur als smtp server in te zetten. De mdaemon server is simpelweg een reeds bestaande mailserver. Zitten dus compleet los van elkaar.

[nelizmastr]

PFY schreef op donderdag 27 oktober 2022 @ 16:52:
[...]


Probeer de exchange bak puur als smtp server in te zetten. De mdaemon server is simpelweg een reeds bestaande mailserver. Zitten dus compleet los van elkaar.

Maar je MX staat kennelijk naar je mdaemon en daar mag je Exchange niet zomaar overheen relayen

Waar staat je send connector in Exchange naartoe?

[Voor 6% gewijzigd door nelizmastr op 27-10-2022 18:50]

[PFY]

De mx voor dat domein gaat naar de server met Exchange erop.
Dus ip.ip.ip.ip a record 5 minuten (server.domeinnaam.eu)
Mx record 10 server.domeinnaam.eu

Die server heeft alle certificaten. Servernaam.domein.eu. Owa.domeinnaam.nu, mail.domeinnaam.eu en webmail.domeinnaam.eu

De send connector heb ik op de internet modus gezet. Delivery gaat via mx record associated with recipient domain..hhhmmmmzzz . ( staat dit soms fout ?) De mail connector werd geblokkeerd door Ziggo op poort 25, dus die heb ik geswitched naar 587. En mijn ontvangende mailserver (die helemaal los staat van deze exchange bak ziet dus wel een verbinding, echter die vind dat dit geauthenticeerd moet worden.

Normaal gesproken had ik ook even bij Mdaemon kunnen aanhaken, maar die zijn gehacked en al een week of langer offline. ( ze adverteren met alllerlei securitygateways etc, maar nu zijn ze zelf de klos)

De gedachte was dat de Exchange server zelf de mail het internet op stuurt (net als mdaemon), echter zo te zien heb je daar smart hosts of specifieke connectors voor nodig ?

Nog even een transcriptje van de communicatie.

Thu 2022-10-27 21:44:49.782: Session 223724; child 0002
Thu 2022-10-27 21:44:49.782: Accepting SMTP connection from 217.x.x.x:35073 to 80.x.x.x:587
Thu 2022-10-27 21:44:49.802: --> 220 mail.ontvangendeserver.nl ESMTP MSA MDaemon 16.5.1; Thu, 27 Oct 2022 21:44:49 +0200
Thu 2022-10-27 21:44:49.817: <-- EHLO mail.verzendendeserver.eu
Thu 2022-10-27 21:44:49.819: --> 250-mail.ontvangendeserver.nl Hello mail.verzendendeserver.eu [217.x.x.x], pleased to meet you
Thu 2022-10-27 21:44:49.820: --> 250-AUTH LOGIN CRAM-MD5 PLAIN
Thu 2022-10-27 21:44:49.820: --> 250-8BITMIME
Thu 2022-10-27 21:44:49.820: --> 250-ENHANCEDSTATUSCODES
Thu 2022-10-27 21:44:49.821: --> 250-STARTTLS
Thu 2022-10-27 21:44:49.821: --> 250 SIZE
Thu 2022-10-27 21:44:49.836: <-- STARTTLS
Thu 2022-10-27 21:44:49.836: --> 220 2.7.0 Ready to start TLS
Thu 2022-10-27 21:44:49.860: SSL negotiation successful (TLS 1.2, 384 bit key exchange, 256 bit AES encryption)
Thu 2022-10-27 21:44:49.920: <-- EHLO mail.verzendendeserver.eu
Thu 2022-10-27 21:44:49.921: --> 250-mail.ontvangendeserver.nl Hello mail.verzendendeserver.eu [217.x.x.x], pleased to meet you
Thu 2022-10-27 21:44:49.921: --> 250-AUTH LOGIN CRAM-MD5 PLAIN
Thu 2022-10-27 21:44:49.921: --> 250-8BITMIME
Thu 2022-10-27 21:44:49.921: --> 250-ENHANCEDSTATUSCODES
Thu 2022-10-27 21:44:49.921: --> 250 SIZE
Thu 2022-10-27 21:44:49.931: <-- MAIL FROM:<[e-mail]> SIZE=4085
Thu 2022-10-27 21:44:49.933: --> 530 5.7.0 Authentication required
Thu 2022-10-27 21:44:49.946: <-- QUIT
Thu 2022-10-27 21:44:49.946: --> 221 2.0.0 See ya in cyberspace
Thu 2022-10-27 21:44:49.946: SMTP session terminated (Bytes in/out: 402/781)

[Voor 71% gewijzigd door PFY op 27-10-2022 21:51]

[sniper20]

Haal je niet het verzenden en ontvangen door elkaar ? MX heb je niet zoveel mee te maken als het probleem het verzenden van mail betreft. Als je Ziggo hebt als internetprovider kun je smtp.ziggo.nl als smarthost instellen met poort 587. Dat zou normaal gesproken moeten werken.

[PFY]

sniper20 schreef op zaterdag 29 oktober 2022 @ 23:28:
Haal je niet het verzenden en ontvangen door elkaar ? MX heb je niet zoveel mee te maken als het probleem het verzenden van mail betreft. Als je Ziggo hebt als internetprovider kun je smtp.ziggo.nl als smarthost instellen met poort 587. Dat zou normaal gesproken moeten werken.

En nu werkt het dus wel. Vermoedelijk doet mijn ontvangende mailserver allerlei checks om te valideren dat de verzendende partij valide is. Echter in dit geval zonder de smart host kon dat niet omdat Ziggo geen poort 25 toelaat om terug te checken of de verzendende partij valide is. Met de smart host van Ziggo (die ik niet kende) wordt kennelijk dit euvel omzeilt.

Nu krijg ik ook netjes een melding terug van mijn ontvangende mailserver. Hello smtpq1.tb.mail.iss.as9143.net (Ziggo) Pleased to meet you.

Nou had ik van de week al beide vm,s naar de servers in Amsterdam geupload, maar moest nog wachten op 2 IP4 adressen voor de AD en Exchange server, maar mooi dat dit nu dus werkt.


Thanks Sniper20