asked on
SMTP Relay Issue
Hi,
We have an issue where we have a business application that sends emails via a SMTP relay (Microsoft IIS) .
Authentication is set to "Anonymous Access", Relay Restrictions set to a list of servers that is allowed to Relay From.
So two things, one, we now want to deploy this app to all users thick clients, which means we either need to lift the restriction or find another authentication mechanism. I personally dont want to open up all internal subnets to be able to relay, especially if a malware begins spamming.
What are my other options? Ideally, I would like to allow all internal subnects to relay but place a service account username and password in the app (which we can do as the app is internally developed) which only that account has rights to relay. Can I do this?
I don't want to use Integrated AD authentication or Exchange Authentication as an malware can just pass the user credentials the user has already logged into their thick clients with.
Or is there a better solution that I should look at? What is the best practice around this?
Thanks in advance.
We have an issue where we have a business application that sends emails via a SMTP relay (Microsoft IIS) .
Authentication is set to "Anonymous Access", Relay Restrictions set to a list of servers that is allowed to Relay From.
So two things, one, we now want to deploy this app to all users thick clients, which means we either need to lift the restriction or find another authentication mechanism. I personally dont want to open up all internal subnets to be able to relay, especially if a malware begins spamming.
What are my other options? Ideally, I would like to allow all internal subnects to relay but place a service account username and password in the app (which we can do as the app is internally developed) which only that account has rights to relay. Can I do this?
I don't want to use Integrated AD authentication or Exchange Authentication as an malware can just pass the user credentials the user has already logged into their thick clients with.
Or is there a better solution that I should look at? What is the best practice around this?
Thanks in advance.
Email ProtocolsMicrosoft IIS Web ServerEmail SoftwareEmail Servers
Last Comment
Daniel Garcia
ASKER
Hi Lester,
Thanks for your response. So instead of using a IIS SMTP virtual server you are suggesting that we create a new SMTP Receive connector on Exchange and setup Authentication as TLS only? In permission group, do I set up "Exchange users"?
Should I add a different IP to the receiver to minimise the chance of other exchange users being able to authenticate on this receiver? ( I am assuming that this setup also allow any exchange user to use this reciever to relay should they know the DNS/IP of the receiver?)
Thanks for your response. So instead of using a IIS SMTP virtual server you are suggesting that we create a new SMTP Receive connector on Exchange and setup Authentication as TLS only? In permission group, do I set up "Exchange users"?
Should I add a different IP to the receiver to minimise the chance of other exchange users being able to authenticate on this receiver? ( I am assuming that this setup also allow any exchange user to use this reciever to relay should they know the DNS/IP of the receiver?)
You don't create a new SMTP receive connector - just use the Client Frontend one :) It's already set to accept basic authentication with TLS. No additional IP's needed either. You won't conflict with Outlook or anything else, you're just using what Exchange has provided to you out of the box. I've highlighted the one I would refer to (this is of course on one of my Exchange Servers).
![Client Frontend Connector]()
NOTE: This is port 587 - not 25 as I originally said.
NOTE: This is port 587 - not 25 as I originally said.
Hi Daniel,
If it is internal to your network of Exchange no need additional settings to relay.
Please mention the Exchange version.
Thanks
MAS
If it is internal to your network of Exchange no need additional settings to relay.
Please mention the Exchange version.
Thanks
MAS
ASKER
Exchange 2013
ASKER
thanks lester. But is it better in terms of security to have another receiver with a different IP? I am concerned about a SMTP auth attack using this receiver. I want my configuration to be apart from current config for if any future SMTP Auth attack occurs, my configuration won't be a factor in the investigation as traffic is diverted to a separate receiver with a different address. Or am I being to pendantic?
Daniel,
Please run these command from a telnet client or Putty from your apps server and post the result.
Please run these command from a telnet client or Putty from your apps server and post the result.
Telnet <Exchange2013IP> 25
EHLO contoso.com
MAIL FROM: <email-configured-in-ur-apps>@youremaildomain.com
250 2.1.0 Sender OK
RCPT TO: daniel@youremaildomain.com
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Hi MAS,
220 credit-sydexch4.lan.credit
Mon, 22 Aug 2016 13:35:01 +1000
EHLO creditcorp.com.au
250-credit-sydexch4.lan.cr
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
MAIL FROM: test@creditcorp.com.au
250 2.1.0 Sender OK
RCPT TO: dgarcia@creditcorp.com.au
250 2.1.5 Recipient OK
220 credit-sydexch4.lan.credit
Mon, 22 Aug 2016 13:35:01 +1000
EHLO creditcorp.com.au
250-credit-sydexch4.lan.cr
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
MAIL FROM: test@creditcorp.com.au
250 2.1.0 Sender OK
RCPT TO: dgarcia@creditcorp.com.au
250 2.1.5 Recipient OK
ASKER
Thanks Lester. It appears there is no ideal solution that secures SMTP then.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
THanks guys you have cleared up for me what was an ambigious solution
If you are not able to build TLS into your application, then you can change your "Client Frontend" connector, and uncheck the box "Offer basic authentication only after starting TLS"