Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit :
On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote:
Some of our users use o365 but would like to use our service for outgoing
mails. We are offering smtp sending services. Integrating our service in
o365 is tricky, as one can only specify a smarthost but microsoft does not
offer any kind of authentication for smarthosts.
Are these individual users or cloud-hosted domains? Who's authorized
to ask Microsoft to route their outbound traffic through your relay?
Can you distinguish one such Office365 sender from another? ...
What's the point (if I may ask) of having their mail sent through
your relay? I assume that Microsoft could quite easily send their
outbound traffic directly to its destination.
Cloud-hosted domains is "hosting" service. You have the control on the
outbound routing.
There is many reason why you want your outbound traffic not directly
delivered to its destination.
Some want to provide "value added services". In my case is is because
the o365 users are only a fraction of my users (hybrid cloud mode) and
that inboud/ouboud internet mails policy/routing/delivery is under the
control of another infrastructure.
Microsoft is always presenting a client certificate. That the only way
to authenticate O365. (the experimental certificate matching will help you)
For the next part, the complete missing of outbound SMTP AUTH (under the
control of Microsoft or the client organization) is the difficult/crazy
part.
The easy/lame way is to match the "under Microsoft control"
X-MS-Exchange-CrossTenant-id header and the SMTP From domains to
filter/differentiate o365 customers.
The "proper" Microsoft way is to use their proprietary XOORG SMTP
extension used in their hybrid cloud scenario.
=> after having authenticated o365 with the presented client
certificate, if you announce the XOORG extension in the EHLO, o365 will
provide you the remote o365 organization (in the "MS Exchange" sense) as
part of the MAIL FROM verb.
MAIL FROM: <m...@my-company.com> OORG=my-organization.com
I have implemented the client part in postfix to not have to deploy 40
Microsoft Exchange Edge servers in a multi-tenant hybrid cloud scenario
and use only my existing postfix infrastructure between o365 and all my
Exchange platforms. It is the easy part. A few simple lines of code. I
don't know what Wietse and Viktor will think about it, so I did not
submit it yet... Will do. Would be great if it could be integrated in
one form or another.
The hard part is the server part. Will do it some day to simplify our
tenants authentication, but I think that it will be more controversial
and will understand if Wietse and Viktor do not want such thing in Postfix.
As it is a SMTP extension, I did not find a generic mechanism in which
XOORG would fit and which could be added to postfix.
For my use case, as I've done for another reason for the certificate
case, I will add the possibility to silently map an XOORG value to a
SASL id to do proper source domain ownership filtering
(reject_xx_login_mismatch mumbles).
Emmanuel.
