Le 17/06/2019 à 13:14, Wietse Venema a écrit :
Emmanuel Fust?:
The "proper" Microsoft way is to use their proprietary XOORG SMTP
extension used in their hybrid cloud scenario.
- Is there a protocol definition for this, or is there only
implementation by trial and error?
The only official statements by Microsoft about these are in this recent
blog post:
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238
Otherwise you will find some random informations on random blogs from
anonymous or "value added" vendors.
We verified these by reversing the exchange 2016 code, do tests with
openssl s_client after proper configuration of our Exchange testing
platform and add the client support in postfix. No fancy config, just
define a smtp_xoorg parameter on a specific transport using a specific
client certificate.
- How is the XOORG information verified against other information
(certificate, header) that is passed in a mail transaction?
XOORG capability is announced and accepted by the (Exchange) server only
for a valid (authority wise) client certificate matching a specific CN.
(could be customized with the TlsCapability on the Exchange side).
In the standard O365 cloud scenario, you authenticate the SMTP session
with the classic validation of the certificate : You know that it is
Microsoft and that it is O365 (cn=xxxx sorry bad memory, enable
smtpd_tls_ask_ccert and you will get it, it is what the "hybridation
wizard" will configure in the TlsCapability of your Exchange edge server).
At this point, the XOORG value is know to be genuine, it is under
Microsoft control, not tenant owner.
All the other 'could/o365" informations passed as headers to Microsoft
Exchange (cross-tenant-ID, X-OriginatorOrg etc...) are now trusted.
Your Exchange server will now flag the email as "internal" (hybrid
cloud") if the XOORG value passed during the SMTP transaction is a
recognised/configured one.
On the other side, when our are on O365, the headers are
generated/sanitized by Microsoft and you base your policy on it. For
on-premise -> o365, they don't use the XOORG extension (it is never
announced). On your tenant, you configure an specific "inboud connector"
which should match a specific client certificate CN (which should
publicly validate) or a list of IPs .... No SMTP-AUTH ....
It would be unsafe to accept XOORG from anyone without further
verification.
Exactly. XOORG is totally moot without client certificate validation and
matching.
Emmanuel.
