Le 17/06/2019 à 20:29, Wietse Venema a écrit :
Emmanuel Fust?:
Le 17/06/2019 ? 12:05, Emmanuel Fust? a ?crit?:
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)
I suppose that Postfix should not accept arbitrary client certificates,
so this certificate check will need to be configurable.
Yes.
In the o365 case, the certificate CN is unique and the same for all o365
servers and not differentiated by hosted customers.
A global map is need to announce or not XOORG based on the client
certificate (verified and matching by CN in the o365 case).
Next, to be generic (and not o365 only/hybrid o365 only) you need a way
to be able if needed to filter which ccert is tied to which oorg with
something like reject_*_sender_ccert-oorg_mismatch.
It's different from the case where we want to use the same map
irrespective from the used mechanisms (sasl -> from email, ccert -> from
email, oorg-> from email) and for witch I would overload/generalize the
SASL login to reuse reject_*_sender_login_mismatch.
More in my other answer.
Emmanuel.
