Am 08.11.2022 um 12:25:52 Uhr schrieb Otto J. Makela:

However, in theory it would be possible that a spammer operation could
set up their own domain on M365 and configure it to use our outgoing
email server, as my only access control currently is the IP netblocks.
This could be prevented if I only accepted from those neblocks emails
that also originate from our own domain(s).

And that isn't sufficient because the attacker could (if MS allows it)
set the MAIL FROM: to whatever they want.

They only way to avoid this is to use auth or make sure your mails come
from IP addresses that are only assigned to you and can't be used by
anybody else.

With IPv6 this should be possible if MS provides such a service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I have a situation where I need to use our sendmail-based frontend
(authoritive to our domains) to relay outgoing emails originating from cloud-based M365 mailbox servers. In practice this means that the
sendmail installation needs to accept incoming emails originating from
rather large swathes of Microsoft net space and forward them onwards to
their final recepients.

Unfortunately M365 does not seem to support any (standard) method of authentication for the outgoing mail server, it's a direct connection to
port 25 and that's pretty much it. Color me surprised.

Parking an email domain on the M365 system involves some verification
steps (including checking that the domain has not already been
registered), so ostensibly nobody else would be able to send out emails
from there using our domain(s).

However, in theory it would be possible that a spammer operation could
set up their own domain on M365 and configure it to use our outgoing
email server, as my only access control currently is the IP netblocks.
This could be prevented if I only accepted from those neblocks emails
that also originate from our own domain(s).

Before this, I've never had the need to combine IP address + originating
email address checks on sendmail, and my google-fu just isn't sufficient
here. How would one typically do this kind of limitations?

--
/* * * Otto J. Makela <[email protected]> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/11/2022 11.25, Otto J. Makela wrote:

Unfortunately M365 does not seem to support any (standard) method of authentication for the outgoing mail server, it's a direct connection to
port 25 and that's pretty much it. Color me surprised.

However, in theory it would be possible that a spammer operation could
set up their own domain on M365 and configure it to use our outgoing
email server, as my only access control currently is the IP netblocks.
This could be prevented if I only accepted from those neblocks emails
that also originate from our own domain(s).

I would have looked at using dkim to verify if the mail is from an authenticated sender from your mail domain, you would first need to
enable dkim in ms365 https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide

Then the sendmail would need to use mimedefang (or something similar) to
filter mail, only allow mail that has a valid dkim and it's from your
domain. Even if someone else would fake your domain, they will still
need to have the private key to sign the dkim, which I would assume they
don't and those do not have a valid dkim.

Of course things feels a bit brittle, a small error and anyone would be
able to user your sendmail as open relay.

I have no experience of this at all, just something that felt more
secure than allowing a big span of ip's.



Not sure about the ms-365 connectors, it looks like you could have one
from ms-365 to your sendmail, not sure if this will include outgoing
mail or not. https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail

--

//Aho

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marco Moock <[email protected]> wrote:

Am 08.11.2022 um 12:25:52 Uhr schrieb Otto J. Makela:

However, in theory it would be possible that a spammer operation
could set up their own domain on M365 and configure it to use our
outgoing email server, as my only access control currently is the IP
netblocks. This could be prevented if I only accepted from those
neblocks emails that also originate from our own domain(s).

And that isn't sufficient because the attacker could (if MS allows it)
set the MAIL FROM: to whatever they want.

As I earlier said, as far as I know, this M365 cloud version of Exchange
will only allow domains you have registered as your own in the MAIL FROM
and email message From fields. This of course is 2nd hand knowledge.
--
/* * * Otto J. Makela <[email protected]> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)