1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • Re: Using sendmail as front end for cloud M365: access control

    From Marco Moock@21:1/5 to All on Tue Nov 8 11:46:30 2022
    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)
  • From Otto J. Makela@21:1/5 to All on Tue Nov 8 12:25:52 2022
    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 * * * * * * */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J.O. Aho@21:1/5 to Otto J. Makela on Tue Nov 8 14:04:28 2022
    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)
  • From Otto J. Makela@21:1/5 to Marco Moock on Tue Nov 8 16:42:03 2022
    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 * * * * * * */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Otto J. Makela on Tue Nov 8 13:34:34 2022
    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.

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