Emmanuel, thank you. That was of great help to see, that others have same isses with o365.
Do you have any more infos how you do the experimental certificate matching part with postifx? thank you in advance Stefan Am Mo., 17. Juni 2019 um 12:05 Uhr schrieb Emmanuel Fusté < emmanuel.fu...@external.thalesgroup.com>: > 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. >
