Le 17/06/2019 à 21:31, Wietse Venema a écrit :
Viktor Dukhovni:
On Mon, Jun 17, 2019 at 02:29:05PM -0400, Wietse Venema wrote:
I suppose that Postfix will need to forward the OORG information
that it received from the Microsoft server, not a name that is
hard-coded in main.cf, and that Postfix will need to send that
information only to systems that should receive it, not to random
systems on the Internet.
Really no need to forward OORG. It was not designed as an end to end
mechanism.
It its only stamping email from coming from this or this hosted
organization without guaranties that they are doing sane things.
OORG value has no meaning downstream, but need to be used in the access
and relay policy: dedicated family of restrictions or SASL mapping to
reuse some (reject_*_login_mismatch).
Cloud/hosting providers could be trusted but without OORG information,
it is the same as blindly thrusting the Internet.
The cloud/hosting provider is acting as a multiplexer and we need to
de-multiplex the flow, without presuming or relying on any inner in-band
mechanism (DKIM).
If going further, OORG must not be passed downstream but a way to tag
some flow should be provided. With that, nothing prevent you to put the
same tag as inbound (if there was any).
I'm not a networking expert, but it could be view as an MPLS mechanism
for SMTP....
It could help to solve a lots of thing in classic SAS/Cloud scenario,
and is unavoidable in "hybrid" configurations.
For the o365 hybridization case, destination domain is sufficient to
determine the OORG to put for downstream Exchange servers as o365<->on
premise emails use a "technical SMTP routing domain"
(xxx.onmicrosoft.com) and custom transport fit well and keep the
implementation minimal.
My case for inbound emails: -> Exchange
Office365-> inbound postfix -> routing, filtering layers etc->
internal outbound postfix -> Exchange
(OORG access control) (o365
OORG spoofing) -> ........
|_________|________________________________________________________________________________|___________________________|
Internet Big Corp trusted central
zone Big corp branches/societies
With the OORG replaying at the oubound, Exchange will promote these
emails as internal, enabling the use/trust of all the specific Exchange
headers coming from o365.
XOORG would need to be accepted only from suitably authenticated and
authorized clients (those trusted to deliver authentic information).
XOORG feels clumsy, a cleaner choice would be DKIM, which supports
passage through untrusted relays, ... but at the cost of breaking
when the content is modified. XOORG on the other admits content
modification, ... but at the cost of requiring trusted relays. If
we're willing to generally forward DKIM signatures, I am not sure
that XOORG needs censoring on the outbound leg, when trusted on the
inbound leg.
The latter is simply conservative design. There is no need to forward
this information, and a receiving system might object to receiving
XOORG from a Postfix machine that isn't authorized to send it.
Yes, XOORG is not a end to end mechanism.
It is actually supposed to be used only in o365->MS Exchange Edge case.
Following their use, you should provide the XOORG capability only to a
trusted server which is for Microsoft a server presenting a validated
certificate with a specific CN.
Emmanuel.
