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 fr
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 betwee
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 al
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 ?
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 au
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
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 recip
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
>
> Dum
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
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
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
>
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 t
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
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 su
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,
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
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
> offe
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_destinatio
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
@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,
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 h
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 certifica
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,
> 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
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
25 matches
Mail list logo
