DevHeads.net

OT: Risks & mitigations of allowing an external sender to send to us (with sender 'same domain' as us)

There is an external app server (that is our service provider) that we want
them
to blast emails to a team/department in our organization (email domain @
xyz.com)
but these emails will have the sender to be in same domain as us ie @xyz.com
.

What are the risks of permitting such bypass (ie disable Norelay) in our
MTA
(it's MS Exchange) & if we have to permit it, what mitigations we can put
in place?

Roger

Comments

Re: OT: Risks & mitigations of allowing an external sender to se

By Noel Jones at 05/15/2018 - 13:28

On 5/14/2018 11:23 PM, Roger Goh wrote:
This is not relaying. DO NOT disable any anti-relay controls.

If the service provider sends mail to your internal team with a
allow this and don't need to do anything.

If the service provider also sets the envelope sender address to
your internal domain, AND you use SPF/DKIM/DMARC to prevent
spoofing, then you'll need to exempt the service provider from those
tests.

-- Noel Jones

Re: OT: Risks & mitigations of allowing an external sender to se

By John Stoffel at 05/15/2018 - 11:17

Roger> There is an external app server (that is our service provider)
Roger> that we want them to blast emails to a team/department in our
Roger> organization (email domain @xyz.com ) but these emails will
Roger> have the sender to be in same domain as us ie @xyz.com.

Roger> What are the risks of permitting such bypass (ie disable
Roger> Norelay) in our MTA (it's MS Exchange) & if we have to permit
Roger> it, what mitigations we can put in place?

Don't let them bypass at all, just give them a login to your mail
system with the appropriate limitations, so that they submit via port
587. This is how I have my hosted domain handle email from my iphone
and other IMAP devices.

This also means you can assign them a specific sender ID, so you can
track them better.

In your master.cf, you would have something like this for the
submission service:

submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_non_fqdn_recipient,reject_unauth_destination

And of course allow them access to port 587 on the mail server from
their listed MX servers, or their listed dedicated servers.

John