I don't think it's a global change by Microsoft.
If you're correct that the error is a certificate issue, it is within the realm
of possibilities that a particular O365 customer (provided
*.eurprd08.prod.outlook.com is O365) has created a send connector for a domain
that you host (or not, if they really screwed it up), requiring a trusted
certificate, as opposed to a self-signed cert. They can additionally require a
specific domain or wildcard (*.example.com) be listed in the subject
name/subject alt name field of the trusted certificate presented.
However, it has been my experience that Microsoft does not allow you to set
Connectors that don't succeed during the config process. Eg: If the test email
fails to transmit, O365 does not allow the customer to save the connector
config. Now, I have no clue how that is enforced through PowerShell... but
since the GUI is basically PS wrapped with nice buttons and input fields, I'd
hope the experience is uniform.
-joe
On 5/19/2021 at 3:33 AM, "Wolfgang Rosenauer via mailop"
wrote:
>
>Hi,
>
>I see increasing reports that sending from MS365 (and similar)
>fails
>with messages like these:
>
>Server at *.eurprd08.prod.outlook.com returned '550 5.4.318
>Message expired, connection reset
>(SuspiciousRemoteServerError)(450
>4.4.318 Connection was
>closed abruptly (SuspiciousRemoteServerError))'
>Server at XYZ returned '450 4.4.318
>Connection was closed abruptly (SuspiciousRemoteServerError)'
>
>There are some pointer that it might be related with TLS and
>certificates.
>Actually there really is for that target a configuration in use
>that the
>MX record name does not match the certificate dn but this was
>never a
>problem so far and I'm not sure if that is causing the issues.
>
>Did MS introduce some feature/setting to do strict checking on TLS
>certificate names and MX DNS names?
>
>
>Thanks,
> Wolfgang
>___
>mailop mailing list
>mailop@mailop.org
>https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
