Relaying?

[tmpadmin]

I think my server is/was being used as a relay server. I admit I am not fully versed in Exchange so I apologize if this is a basic question.

I keep getting errors of mails that were not sent. Normally this isn't a big deal but the sender is listed as <> Here are two I got this weekend.

A mail message was not sent due to a protocol error.

554 5.6.0 All recipients discarded by mail filter
The message that caused this notification was:


To: <bounceback@greygmail.com>
From: <>
Subject: Delivered: Save $25 on a last minute trip today!

A mail message could not be sent because the following host is unknown:

topsitemarketing.com
The message that caused this notification was:


To: <offer@topsitemarketing.com>
From: <>
Subject: Undeliverable: 10 Millions Domains For You

Upon looking at this further I see that they are not being sent which is good but there is the attempt which I want to prevent. Would simply taking my exchange box off the public wan and putting it oh my DMZ port help this?

Thanks for you help

 

[Zelandakh]

Reverse UCE. If you set your system to Do not reroute incoming SMTP mail, malicious users can use your system as a launching point to flood another computer system with SMTP messages. Because the messages include your company's address, they look as if you sent them. For a more detailed look at the SMTP protocol dialog between sender and server, see Mark Minasi's Windows NT Magazine article &quot;Untangling Email&quot; (April 1998).

As the system issues each of these commands, the Exchange server returns a code to the sending system. All the server responses in the dialog start with a numerical code. This code is either 250 OK, which represents success, or another error code, such as 501 Unrecognized parameter. The SMTP protocol specifies that 200-level codes signify success, 400-level codes signify temporary failures, and 500-level codes signify critical failures.

The logic that the IMS uses when determining whether to deliver a message flows as follows:

Accept sender's address.
Accept recipient's address.
Accept a data stream containing message header and body text.
Determine whether the recipient is a member of the local system (i.e., whether the address is in the Global Address List—GAL).
If yes, deliver the message to the local recipient. If no, use the sender's address to generate an NDR.
Because step 5 can result in the system directing a message back to the sending address, a malicious user could engineer a mail flood by supplying a bogus addressee (RCPT TO) with a valid sending address (MAIL FROM)—the target of the flood—and then infinitely generating messages to the Exchange IMS. In any case, the malicious user achieves the objective of getting an unsolicited message to a destination.

Unnecessary burden on system. You can see the second disadvantage of using the Do not reroute incoming SMTP mail setting by reading the SMTP dialog. You're providing the IMS with the following information: the message sender (MAIL FROM), the message recipient (RCPT TO), and the message (DATA). When your POP3 client sends a message, as in this test, it goes through a similar process. In the current configuration (Do not reroute incoming SMTP mail), the IMS accepts the RCPT TO specification and sends the return code 250 OK even if the recipient isn't part of the local system. Next, the IMS lets you execute the DATA command, through which you could supply megabytes and megabytes of message body text. This action can tie up your system resources, even though the system eventually generates an NDR.

A Better Option
If you attempt to perform these operations on most UNIX hosts that you've configured to prevent relaying, you'll receive a 550 Relaying prohibited SMTP error code when you specify the nonlocal recipient. This result is more desirable, meets the RFC recommendation, and eliminates the two flaws I just described. In this configuration, the IMS proceeds through only four steps before preventing a relay.

Accept sender's address.
Accept recipient's address.
Determine whether the recipient is a member of the local system (i.e., whether the address is in the GAL).
If yes, return 250 OK and accept the recipient; if no, return 550 Relaying prohibited (don't proceed to steps 5 and 6).
Accept a data stream containing message header and body text.
Deliver the message to the local recipient.


As you may be able to guess, I've lifted it from a web site. I'll get the URL for you.