[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1101
  • Last Modified:

SMTP server for internal delivery only

Hello, we have a situation where certain internal applications are not allowed to send mail externally but only to internal receipents and since the hosts or sender addresses are not fixed it does not seem possible to implement this restriction at the main Exchange mail server itself but has to be a separate SMTP.
It seems to be a rather trivial problem as I only need a service that responds to SMTP requests and forwards them to the main mailserver provided the destinations are for internal use.

I  first thought that this was feasible from the inbuilt Windows 2003 IIS6 SMTP server but I really cannot see any options for explicit forwarding to another SMTP nor any filtering capabilites on destination addresses so that seems to be a dead end.
My next step was to trying to find a freeware (it unfortunately needs to be free) SMTP gateway software but so far I have not been able to find anything that satifies the criterias to be free AND supports forwarding to another SMTP with destination filtering capabilites.

It seemed to be a rather trivial issue so are there any software/ IIS SMTP plugins that could be of assistance in this matter?
At the very worst it might be possible to set up a SMTP on a LINUX server but in that case needs a very simple implementation since my LINUX knowledge is limited to say the least.     Thanks in advance!

0
AndersBiro
Asked:
AndersBiro
1 Solution
 
tigermattCommented:

You don't need another SMTP server. All you need is another SMTP Virtual Server on the Exchange Server, which is configured such that users must authenticated with a username/password, and only those authenticated users can relay. This can either run on a second IP address assigned to the Exchange Server, or on another port (such as port 26). Applications are then directed to the other IP/port and supplied with the credentials, and they will be allowed to connect and relay, internally or externally.

I would not over-complicate matters though; I would simply maintain a list of IP addresses of the device(s) which need relay access in the 'Relay' section of the main SMTP Virtual Server.

-Matt
0
 
AndersBiroAuthor Commented:
I am not sure that this is a viable option though since the applications is written in such a way in order to utilize an anonymous SMTP-server at port 25 and I do not think it is possible to configure them to a  user authenticated SMTP-server instead.

Another problem is that it is not easy to separate and predict the IP-addresses that will be used for regular mail vs application access so it does not seem possible to restrict the relaying on IP only.
0
 
MesthaCommented:
If the servers are only sending to internal recipients then you do not need to do anything different to Exchange. Just have the machines send email to the Exchange server on port 25. If they attempt to send to an external recipient Exchange will just kick the message back with an unable to relay option.

Simon.
0
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 
AndersBiroAuthor Commented:
That is the thing, I need to prevent the servers from sending mail to external recepients and still enable other internal STMP clients to send external mail as well.
Basically we have two usage profiles here:

1. Application servers that sometimes generate mail to external receipments but are only allowed to deliver mail to internal recipients (external mail attempts must be filtered out since the application cannot be modified in that regard)

2. Other internal users that need to send to both internal and external destinations

Since the servers in #1 does not have any distinguishable pattern of known hosts/sender addresses etc it does not seem to be possible to differentiate them at the Exchange server and seems to me that separare SMTP servers  are the only way?
0
 
tigermattCommented:

If you want to stop the application from sending external email, simply do not make any changes Exchange. That will allow the applications to send email direct to internal recipients, and email to external recipients will be bounced.

Internal users of the Exchange Server will still be able to send email. They should be connected via Outlook (using an Exchange Server MAPI/Outlook Anywhere connection) or using Outlook Web Access.

-Matt
0
 
AndersBiroAuthor Commented:
Yes, as a matter of fact I had this solution in mind first but it turned out that there were some internal servers that actually need to send external mail through SMTP as well so some relaying is needed.

However, when I think about it now then perhaps the easiest solution is just to restrict relaying to these individual hosts which hopefully should not be too hard in Exchange 2007 so I will give this idea a try.
0
 
tigermattCommented:

That will work. Simply restrict relay on a new receive connector to a pre-defined list of IP addresses (the servers which need relay access): http://technet.microsoft.com/en-us/library/bb232021.aspx.

-Matt
0
 
AndersBiroAuthor Commented:
That seems like a plan but I am unfortunately a bit confused with the Exchange 2007 connector setup as I noticed that the primary receive connector supports relay as well and I cannot get this setup to work unless relaying is allowed only for the restricted secondary connector.

The primary connector has "Anonymous users" as its permission group and if i understood the link correctly then relaying is only possible if you explicitly assign it the Extended Right  "Ms-Exch-SMTP-Accept-Any-Recipient" and I could confirm that this was not assigned by the CMD-Let command:

"Get-receiveConnector "Internal mail"|Get-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON"

Identity             User                 Deny  Inherited Rights
--------             ----                 ----  --------- ------
MAIL\Internal mail  NT AUTHORITY\ANON... False False     ms-Exch-SMTP-Submit
MAIL\Internal mail  NT AUTHORITY\ANON... False False     ms-Exch-SMTP-Accept-Any-Sender
MAIL\Internal mail  NT AUTHORITY\ANON... False False     ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
MAIL\Internal mail  NT AUTHORITY\ANON... False False     ms-Exch-Accept-Headers-Routing
MAIL\Internal mail  NT AUTHORITY\ANON... False True      GenericRead
MAIL\Internal mail  NT AUTHORITY\ANON... False True      ms-Exch-Store-Create-Named-Properties
MAIL\Internal mail  NT AUTHORITY\ANON... False True      ms-Exch-Create-Public-Folder


However, it is still possible to telnet a SMTP-mail message to an external receipent so clearly mail relay is still in place so are there any other relevant settings in order to disable mail relay for a connector?



0
 
lanboyoCommented:
I don't know what to do with exchange, but essentially you need to configure the exchange server to view the host needing local relay as an external host, and the hosts needing external relay as internal hosts. Generally it will assume hosts that are on it's own ip range as internal.

Be careful as the exchange server will do whatever spam filtering routines it is destined to do on external mail to your devices.

It is a fairly simple postfix config if you decide to go with a linux box.
0
 
AndersBiroAuthor Commented:
The problem has now been identified and taken cared of, in addition to the "Ms-Exch-SMTP-Accept-Any-Recipient" setting Exchange 2007 relaying is also enabled by a wildcard entry under "Hub transport->Accepted Domains".
Once I removed this entry relaying was disabled and all I needed to do was to add a new connector for dedicated relay hosts, assigning "Ms-Exch-SMTP-Accept-Any-Recipient" to that one and leaving the default connector in non-relay mode which now works like a charm.


0

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now