|
Allowing a machine to relay SMTP messages means that your SMTP Server will accept messages from that machine that are not intended for the SMTP Server's domain(s) and that your SMTP Server will forward the message to the SMTP Server responsible for accepting incoming messages for the recipient's domain.
In a perfect world, you should have authority and control over all systems that are relaying messages through your SMTP Server. Without this direct control, your only means of controlling them is by configuring an SMTP connector or by configuring the default SMTP virtual server with restrictive settings for inbound and outbound messages.
Remember, relaying means that an SMTP client can use an SMTP server to forward e-mail messages to a remote (in other words, non-local) domain. Relaying itself is not inherently bad, because SMTP was designed for this purpose (see, e.g., sections 2.1 and 3.7 of Remote Function Call (RFC) 2821).
However, if relaying is not controlled, a malicious user might use it to send bulk spam or UCE (unsolicited commercial e-mail). This ties up resources on the relay host, which could prevent it from sending e-mail messages. In other words, the security risk is a denial of service against your SMTP server.
I would look into using SMTP authentication, restricting which hosts can relay and tightening your SMTP virtual server/connector restrictions. Alternatively, you might just have the folks who need SMTP services set up their own IIS SMTP server. It's quick, easy and free.
|
