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 <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

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.

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

Marco Moock <mo01@posteo.de> 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 <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Otto J. Makela wrote:

> This could be prevented if I only accepted from those neblocks emails
> that also originate from our own domain(s).

Seems you need to write your own custom ruleset.
If you want something like this:
if client ip matches a certain range
then
envelope sender must have @your.domain
Correct?

See cf/README about Local_check_mail:
These rules are called with the original arguments of the corresponding
check_* ruleset. ...
.... Return values that do not start
with $# are ignored, i.e., normal processing continues.

So use
LOCAL_RULESETS
SLocal_check_mail
# add client address to workspace
R$* $: $&{client_addr} $| $1

then you can use an existing ruleset:

### A: LookUpAddress -- search for host address in access database
### <$1> -- key (dot quadded host address)
### <$2> -- default (what to return if not found in db)
### <$3> -- mark (must be <(!|+) single-token>)
### <$4> -- passthru (additional data passed through)
dnl returns: <default> <passthru>
dnl <result> <passthru>

if there is no match, return.
otherwise get rid of the address
R$* $| $* $: $1
and look up just the address, e.g., using
### D: LookUpDomain -- search for domain in access database

see cf/m4/proto.m4 for details and how to call those
rulesets.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.