Re: authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

I'm glad you're asking. These are cloud-hosted domains at microsofts
exchange online (o365) infrastructure.
Each user can set outgoing routing to smarthosts(called connectors)  in
exchanges admin-center. But - as said, no smtp-authentication is offered.

We're providing sending-capabilities paired with archive & delivery
statistics. So our customers can just sign-up for our services, set there
relayhost (in postfix terms) and we take care of the rest.
Our non-postfix-users, that are having o365 as mail infrastructure, can set
as well a smarthost BUT without any smtp-authentication capability.

Thats our problem. We would like to accept our customer mails, coming from
the MS world, but need some good/strong way, to authenticate them
appropriately.
so far, only sender-domain/address and MS own-published ip-ranges are
factors, we have available.

Am So., 16. Juni 2019 um 22:37 Uhr schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:

> 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.
>
> --
> Viktor.
>

Re: authenticate o365 users with postfix without smtp auth

[Jon Radel]

> On Jun 16, 2019, at 6:38 PM, Bill Cole 
>  wrote:
>
>> On 16 Jun 2019, at 16:27, @lbutlr wrote:
>>
>> On 16 Jun2019, at 12:05, Bill Cole
>>  wrote:
> [...]
>>
>>> As the OP says, they support an outbound "smarthost" connector,
>>
>>
>> Not a term I’ve heard before.
>
> The term "smarthost" dates from the days when it was fairly common for
> some hosts to know more about how to route email than others, the days
> 

I believe the term “connector” is a Microsoftism and best I can explain it is 
that it’s a collection of abstractions of various types for connecting email 
systems. I use some for sending trusted email from on premise Postfix servers 
to several O365 accounts. I specify the source IP addresses, or the CN of the 
TLS cert I’m using, in the connector configuration, and a number of capacity 
controls, filtering for spoofed return addresses, etc. no longer apply.

I’ll note that MS appears fairly serious about depreciating anything other than 
TLS 1.2 with “real” certs and I validate their cert and have them validate 
mine.  Of course, my email is flowing in the opposite direction of the OP’s.

—Jon Radel
Please do not use e-mail to transmit orders for securities or for other 
time-sensitive messages. Securities products and services are offered through 
Folio Investments, Inc. and are subject to investment risk, including the 
possible loss of principal. Member FINRA/SIPC. Folio Investments, Inc. and 
First Affirmative Financial Network, LLC are affiliates. This e-mail message 
and any files transmitted with it are confidential, intended only for the 
person(s) to whom this e-mail message is addressed. If you have received this 
e-mail message in error, please notify the sender immediately by telephone or 
e-mail and destroy the original message without making a copy. This e-mail is 
subject to review, retrieval, archiving and disclosure by Folio to third 
parties.

Re: DANE with own CA

[Viktor Dukhovni]

On Mon, Jun 17, 2019 at 05:33:16AM +0300, Lefteris Tsintjelis wrote:

> > The trust-anchor CA certificate MUST be included in your certificate
> > chain configuration for transmission to the SMTP client.
> 
> Should all the chain certificates be included, CA root and CA
> intermediate for example, as 2 1 1? I believe I saw somewhere that one
> of them should be enough(?).

You publish "2 1 1" records for the CA(s) you actually trust, which
is often an intermediate CA, rather than its issuing root CA.  Whichever
CA that is, the corresponding certificate must be part of the configured
certificate chain transmitted to the TLS (SMTP in this case) client.

> I have used CNAME to point to TLSA and https://dane.sys4.de/ seems to
> verify everything correctly. I am not certain though about how RFC
> "friendly" is to use CNAME to point to TLSA records? Can it be done safely?

Yes.

> > Also see:
> > 
> > https://tools.ietf.org/html/rfc7671#section-8.1
> > https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
> > https://github.com/danefail/list/issues/47#issuecomment-456623996
> > 
> > And talk slides/video at:
> > 
> > https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> > 
> > where I also discuss "2 1 1 + 3 1 1" key rotation.
> 
> Really great and very informative DNSSEC and DANE links.

Thanks, spread the word...

> It would have been really great to
> adopt DANE to more services but that could have very negative impact to
> the "well knowns" CAs.

All in good time, they browser vendors (Google Chrome, Mozilla
Firefox, ...) are not ready yet.

-- 
Viktor.

Re: DANE with own CA

[Lefteris Tsintjelis]

On 14/6/2019 21:18, Viktor Dukhovni wrote:
> 
> The use of private CAs with certificate usage DANE-TA(2) is specified
> for SMTP and supported in Postfix, Exim, ...  See:
> 
> https://tools.ietf.org/html/rfc7671#section-5.2
> 
> The trust-anchor CA certificate MUST be included in your certificate
> chain configuration for transmission to the SMTP client.

Should all the chain certificates be included, CA root and CA
intermediate for example, as 2 1 1? I believe I saw somewhere that one
of them should be enough(?).

I have used CNAME to point to TLSA and https://dane.sys4.de/ seems to
verify everything correctly. I am not certain though about how RFC
"friendly" is to use CNAME to point to TLSA records? Can it be done safely?

> Also see:
> 
> https://tools.ietf.org/html/rfc7671#section-8.1
> https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
> https://github.com/danefail/list/issues/47#issuecomment-456623996
> 
> And talk slides/video at:
> 
> https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> 
> where I also discuss "2 1 1 + 3 1 1" key rotation.

Really great and very informative DNSSEC and DANE links. Too bad all
this is mostly for SMTP for now. It would have been really great to
adopt DANE to more services but that could have very negative impact to
the "well knowns" CAs.

Lefteris

Re: authenticate o365 users with postfix without smtp auth

[Bill Cole]

On 16 Jun 2019, at 16:27, @lbutlr wrote:

On 16 Jun2019, at 12:05, Bill Cole 
 wrote:

[...]



As the OP says, they support an outbound "smarthost" connector,



Not a term I’ve heard before.


The term "smarthost" dates from the days when it was fairly common for 
some hosts to know more about how to route email than others, the days 
before ubiquitous Internet connectivity and before that included DNS 
and/or before DNS was adequate to find the route to all mailable 
domains. So some hosts were smarter than others and it was quite common 
for many hosts to only know a friendly nearby "smarthost."


The terminology remains because the basic model of operation remains 
useful, even when the rationale is no longer how "smart" an outbound 
gateway might be.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: smtpd_reipient_restrictions

[Wietse Venema]

@lbutlr:
> Since I have moved all local users to virtual users and switched dovecot =
> to lmtp from lda, I was able to add reject_unverified_recipient to =
> my restrictions, and it occurred to me maybe some of the other =
> restrictions could be eliminated.
> 
> Do reject_non_fqdn_recipient, reject_unauth_destination, do anything =
> that isn=E2=80=99t done with the check for unverified recipient?

reject_unauth_destination keeps your system from becoming an open
relay.  reject_unverified_recipient is more expensive than
reject_non_fqdn_recipient, so there is some value in keeping the
syntax check.

> Does it matter if there are only hundreds of addresses instead of tens =
> of thousands?

It should not greatly affect table lookup times. An indexed file
has roughly constant time, while trees are logarthmic. But more
recipients mean more probes.

> If nearly all users accounts get at least an email a day, will any =
> probes be done at all after the first day? (That is, how persistent is =
> the persistent database postfix keeps of verified recipients? Does it =
> persists through reloads of postfix, reboots of the system?)

Refresh probes happen when email arrives and a 'postive' stored
result is older than address_verify_positive_refresh_time or a
'negative' stored result is older than address_verify_negative_refresh_time.

The SMTP daemon will not wait for those refresh probes to complete,
as long as the stored result is not expired.

Wietse

Re: authenticate o365 users with postfix without smtp auth

[Bill Cole]

On 16 Jun 2019, at 14:33, Stefan Bauer wrote:


Bill,

yes thats the question. i would consider the two factors as reliable. 
MS is
signing mails. i just like clear user authentication instead of rely 
on

volatile ips/blocks, microsoft publishes/changes.

what i need to check is also, whether MS allows spoofing of sender 
address.


I believe that they do not, so that if you get mail from an O365 
outbound machine (which should be identifiable by SPF) in a domain which 
they believe to be part of the O365 forest, the full envelope sender 
address is trustworthy and, if the DKIM signature verifies, so is the 
From header address.


These of course would only be as trustworthy as O365 user authentication 
in general but that's reasonably good.


i need to make sure, no user can use our service, just by sending 
through

any ms account with a correctly guessed allowed sender address.


I'm not currently managing any O365 domains but to the best of my 
recollection (which is from 2 years ago and is no better than that of 
other humans of my advancing age) they claim to not allow any form of 
unauthorized user impersonation. In other words, one can delegate 
account access to another user but one cannot simply send mail as 
whatever user one likes.


This is a question that MS would surely answer clearly and directly if 
asked by a paying customer, yes? I expect that if you found the right MS 
mail admin in a place where they communicate with the outside community, 
you might get an answer for free even if you were not a paying customer.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

smtpd_reipient_restrictions

[@lbutlr]

Since I have moved all local users to virtual users and switched dovecot to 
lmtp from lda, I was able to add reject_unverified_recipient to my 
restrictions, and it occurred to me maybe some of the other restrictions could 
be eliminated.

Do reject_non_fqdn_recipient, reject_unauth_destination, do anything that isn’t 
done with the check for unverified recipient?

smtpd_recipient_restrictions = reject_unauth_destination
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unknown_sender_domain
reject_unlisted_recipient
reject_unlisted_sender
reject_invalid_hostname
reject_unverified_recipient
reject_unknown_reverse_client_hostname
reject_unknown_client_hostname
permit

The sample block at  
shows this being added late in the list, and after  
reject_unknown_recipient_domain, but is that check necessary when the probe 
postfix does is local (I understand the answer is different when dealing with a 
relay domain that is probing another server).

Does it matter if there are only hundreds of addresses instead of tens of 
thousands?

If nearly all users accounts get at least an email a day, will any probes be 
done at all after the first day? (That is, how persistent is the persistent 
database postfix keeps of verified recipients? Does it persists through reloads 
of postfix, reboots of the system?)



-- 
Do not meddle in the affairs of Dragons for you are crunchy and taste
good with ketchup

Re: authenticate o365 users with postfix without smtp auth

[Viktor Dukhovni]

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.

-- 
Viktor.

Re: authenticate o365 users with postfix without smtp auth

[@lbutlr]

On 16 Jun2019, at 12:05, Bill Cole  
wrote:
> But they do.

Wild.

> As the OP says, they support an outbound "smarthost" connector,

Not a term I’ve heard before.

> This is not such an unusual requirement. I have worked with multiple 
> businesses whose regulatory compliance relies on having all external 
> communication archived in real time to a 3rd party system. This allows users 
> to manage their mailboxes however they like without risking violation of 
> company policy or law. Often a 'global Bcc' is adequate for that but it can 
> be a better fit to put redirection a step away from the mail system handling 
> mailboxes.

I would have thought he way to do this is to use your own host for outbound 
mail, allowing you to archive copies of it however you want, rather than have a 
third party relay mail through you. You can certainly prevent connections out 
to other mail hosts so that your server cannot be bypassed inside your 
network/VPN.

Obviously when out on the open Internet there would need to be a system on 
Microsoft’s side for these sorts of clients, but wouldn’t it be simpler to say 
“Hey, you’re a valid 0365 account, but you are only authorized to used 
[Corporate mail server]?

Using the corporate mail server as a relay struck me (and still strikes me) as 
the bassackwards way to do this, but I assume I am missing something in there.



-- 
He was Igor, son of Igor, nephew of several Igors, brother of Igors and
cousin of more Igors than he could remember without checking up in his
diary. Igors did not change a winning formula. {Footnote: Especially if
it was green, and bubbled.}

Re: authenticate o365 users with postfix without smtp auth

[Peter]

On 17/06/19 2:00 AM, Stefan Bauer wrote:
we are running a small smtp relay service with postfix for authenticated 
users. Unfortunately office 365 does not offer any smtp authentication 
mechanism when sending mails via connectors to smarthosts.


I can't believe I just looked up MS docs for you, but:

https://docs.microsoft.com/en-us/powershell/module/exchange/mail-flow/set-sendconnector?view=exchange-ps

Note the -SmartHostAuthMechanism and -AuthenticationCredential parameters.

For more info please ask in a forum appropriate to o365 or exchange, 
this is not support for exchange.



Peter

Re: authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

Bill,

yes thats the question. i would consider the two factors as reliable. MS is
signing mails. i just like clear user authentication instead of rely on
volatile ips/blocks, microsoft publishes/changes.

what i need to check is also, whether MS allows spoofing of sender address.
i need to make sure, no user can use our service, just by sending through
any ms account with a correctly guessed allowed sender address.

far away from perfect.

Am Sonntag, 16. Juni 2019 schrieb Bill Cole <
postfixlists-070...@billmail.scconsult.com>:
> So if you know that the SMTP client matches SPF (or a statically-set
address set) for the sender domain AND the sender address is one you intend
to service, how reliably is the mail authenticated by those 2 elements
together?
>
> Is the mail DKIM signed?
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>

Re: authenticate o365 users with postfix without smtp auth

[Bill Cole]

On 16 Jun 2019, at 13:40, Stefan Bauer wrote:


MS is publishing source ips/ranges.

sasl_exeptions_networks seems an option but i still dont like the lack 
of

authentication.


So if you know that the SMTP client matches SPF (or a statically-set 
address set) for the sender domain AND the sender address is one you 
intend to service, how reliably is the mail authenticated by those 2 
elements together?


Is the mail DKIM signed?


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)

Re: authenticate o365 users with postfix without smtp auth

[Bill Cole]

On 16 Jun 2019, at 13:18, @lbutlr wrote:


On 16 Jun2019, at 10:48, Stefan Bauer  wrote:

[...]
the last mile o365->recipient should go through our service like 
o365->postfix->recipient


I do not believe any company, much less Microsoft, is going to sent 
emails from their users to other users through your mail server.


But they do. As the OP says, they support an outbound "smarthost" 
connector, it is just missing an authentication functionality.


This is not such an unusual requirement. I have worked with multiple 
businesses whose regulatory compliance relies on having all external 
communication archived in real time to a 3rd party system. This allows 
users to manage their mailboxes however they like without risking 
violation of company policy or law. Often a 'global Bcc' is adequate for 
that but it can be a better fit to put redirection a step away from the 
mail system handling mailboxes.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)

Re: authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

MS is publishing source ips/ranges.

sasl_exeptions_networks seems an option but i still dont like the lack of
authentication.

Am Sonntag, 16. Juni 2019 schrieb Wietse Venema :
> Stefan Bauer:
>> its like the first:
>>
>> end-user client -> microsoft server -> postfix server -> remote recipient
>
> How would Postfix know that the server is Microsoft Office 365?
> From the reverse DNS?
>
> Wietse
>

Re: authenticate o365 users with postfix without smtp auth

[Wietse Venema]

Stefan Bauer:
> its like the first:
> 
> end-user client -> microsoft server -> postfix server -> remote recipient

How would Postfix know that the server is Microsoft Office 365?
>From the reverse DNS?

Wietse

Re: authenticate o365 users with postfix without smtp auth

[@lbutlr]

On 16 Jun2019, at 10:48, Stefan Bauer  wrote:
> our users send/receive via o365.

That’s not what you said. You said "some of our users use o365 but would like 
to use our service for outgoing mails.”

> the last mile o365->recipient should go through our service like 
> o365->postfix->recipient

I do not believe any company, much less Microsoft, is going to sent emails from 
their users to other users through your mail server.



-- 
The Earth is like a tiny grain of sand, only much, much heavier.

Re: authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

its like the first:


end-user client -> microsoft server -> postfix server -> remote recipient

Am Sonntag, 16. Juni 2019 schrieb Wietse Venema :
> Stefan Bauer:
>> our users send/receive via o365. the last mile o365->recipient should go
>> through our service like o365->postfix->recipient
>
> Dumb question: is the mail flow like this:
>
> end-user client -> microsoft server -> postfix server -> remote recipient
>
> Or is it something else?
> - Local recipient?
> - End-user office 365 client -> postfix server?
>
> Please be explicit about the client and server roles.
>
> Wietse
>

Re: authenticate o365 users with postfix without smtp auth

[Wietse Venema]

Stefan Bauer:
> our users send/receive via o365. the last mile o365->recipient should go
> through our service like o365->postfix->recipient

Dumb question: is the mail flow like this:

end-user client -> microsoft server -> postfix server -> remote recipient

Or is it something else?
- Local recipient?
- End-user office 365 client -> postfix server?

Please be explicit about the client and server roles.

Wietse

Re: authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

our users send/receive via o365. the last mile o365->recipient should go
through our service like o365->postfix->recipient

here, o365 does not offer smtp auth against postfix.

Am Sonntag, 16. Juni 2019 schrieb @lbutlr :
> On 16 Jun2019, at 09:46, 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.
>
> You can, and should (and I would say MUST) authenticate your users. You
do not need Microsoft to authenticate them.
>
>> so i'm asking if someone also noticed that and can recommend best
practice to allow o365 to relay via postfix without available sasl
authentication in a secure way.
>
> Why would o365 be relaying via your server?
>
> User connects to your server.
> User authenticates and passes authentication
> User sends email
>
> Where is 0365 involved at all?
>
>
>
>
> —
>
>
>

Re: authenticate o365 users with postfix without smtp auth

[@lbutlr]

On 16 Jun2019, at 09:46, 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.

You can, and should (and I would say MUST) authenticate your users. You do not 
need Microsoft to authenticate them.

> so i'm asking if someone also noticed that and can recommend best practice to 
> allow o365 to relay via postfix without available sasl authentication in a 
> secure way.  

Why would o365 be relaying via your server?

User connects to your server.
User authenticates and passes authentication
User sends email

Where is 0365 involved at all?




— 

Re: authenticate o365 users with postfix without smtp auth

[Benny Pedersen]

Stefan Bauer skrev den 2019-06-16 17:46:

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


cyrus-sasl support rimap, if o365 users can use that ?

if not it would not stop you from make own sasl auth backends for 
custommers, but try rimap first

Re: authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

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.

so i'm asking if someone also noticed that and can recommend best practice
to allow o365 to relay via postfix without available sasl authentication in
a secure way.

I'm just baffled about microsofts move to remove authentication in there
exchange cloud version and howto work around that in a reasonable way.

Am Sonntag, 16. Juni 2019 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
> On Sun, Jun 16, 2019 at 04:00:38PM +0200, Stefan Bauer wrote:
>
>> We are running a small smtp relay service with postfix for authenticated
>> users. Unfortunately office 365 does not offer any smtp authentication
>> mechanism when sending mails via connectors to smarthosts.
>
> There's a giant gap between the first sentence and the second.
> You'll need to explain the use-case in considerably more detail.
>
> Why does Office365 elect to use your relay at all?  Do they limit
> the traffic so routed to just the authorized users?  Are you sure
> they can't/won't use a SASL login or TLS client cert to authenticate,
> in this context.
>
> There's no magic, Postfix can only authorize based on IP address,
> SASL or TLS auth, possibly further constrained by sender address
> (which is never sufficient in isolation).
>
> --
> Viktor.
>

Re: authenticate o365 users with postfix without smtp auth

[Viktor Dukhovni]

On Sun, Jun 16, 2019 at 04:00:38PM +0200, Stefan Bauer wrote:

> We are running a small smtp relay service with postfix for authenticated
> users. Unfortunately office 365 does not offer any smtp authentication
> mechanism when sending mails via connectors to smarthosts.

There's a giant gap between the first sentence and the second.
You'll need to explain the use-case in considerably more detail.

Why does Office365 elect to use your relay at all?  Do they limit
the traffic so routed to just the authorized users?  Are you sure
they can't/won't use a SASL login or TLS client cert to authenticate,
in this context.

There's no magic, Postfix can only authorize based on IP address,
SASL or TLS auth, possibly further constrained by sender address
(which is never sufficient in isolation).

-- 
Viktor.

authenticate o365 users with postfix without smtp auth

[Stefan Bauer]

Hi,

we are running a small smtp relay service with postfix for authenticated
users. Unfortunately office 365 does not offer any smtp authentication
mechanism when sending mails via connectors to smarthosts.

how could one protect smtp submission in another way?

without authentication, everyone from MS ip ranges with valid sender
address could relay through our service. i dont like to open our service
'blind' to MS ip ranges.

Ideas/Thoughts are very welcome.

Stefan