Software

General discussion

Locked

Telnet to port 25

By Choppit ·
I'm experiencing difficulty connecting to my mail server by telnet on port 25. This problem only occurs if I connect from the LAN, in which case the connection is dropped instantly. If I connect from the internet to the firewall IP, the connection is successful. Server is Exchange 5.0(SP2) on NT4(SP6a). TCP Port 25 is forwarded from firewall/router. Any ideas?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

by Choppit In reply to Telnet to port 25

Here's what I'm trying to achieve;
The server is an open relay which as I understand it cannot be prevented with Exch 5.0. I'm trying to implement a 3rd party mail proxy (Sophos MailMonitor SMTP) to prevent relaying and provide AV. However, the Exchange IMC appears to be rejecting connections from MailMonitor and also apparently Telnet connections. Hence I find myself in a situation whereby any host on the WWW can relay through my server except those that I have control of (i.e those on my LAN)

Collapse -

by Choppit In reply to Telnet to port 25

I should add that the only reason I have added the fact that I can telnet to port 110 is to illustrate that the problem only occurs on the SMTP port.

Collapse -

by Choppit In reply to Telnet to port 25

Point value changed by question poster.

Collapse -

by CG IT In reply to Telnet to port 25

yes later versions of exchange are different in that most are run with Active Directory.

You HAVE to be able to telnet to exchange on the LAN. WAN doesn't mean diddly in so far as public people can find your meaning the MX record in DNS points correctly to your IP address and Exchange. That means mail will find you. Getting mail out LAN. Do you have a firewall on somewhere? or some sort of packet filtering?

Collapse -

by CG IT In reply to

telenet test at the command prompt is telnet.exe press enter. next, at the telnet comman prompt type in: set<space>local_echo press enter. next is type in open<space><domainname><space>25 this is for Exchange 2000 testing via telnet on TCP port 25 to verify exchange is listening. you should get a reply "blah blah ESMTP Mail Service Version: blah blah.

I want to say, I believe you have a DNS error in the MX record, that the IP address specified in the record for the LAN is wrong or some other DNS records, ptr or CName, Host name A record has to a wrong ip address in it.

Collapse -

by Choppit In reply to

The issue I have is that I CANNOT telnet to the exchange server IP on port 25 from the local subnet. The exch server receives mail over SMTP without problems provided that the connection is initiated from another subnet. Under normal circumstances this would not be a problem, however I need to use the 3rd party product to relay mail to the exchange server.6

Collapse -

by sgt_shultz In reply to Telnet to port 25

Hi, did you see this already?
XIMS: Microsoft SMTP Servers May Seem to Accept and Relay E-Mail Messages in Third-Party Tests
View products that this article applies to.
This article was previously published under Q304897
SYMPTOMS
If you use some third-party tests to test Microsoft Simple Mail Transfer Protocol (SMTP) servers for relay, the SMTP server may seem to fail the test and your Microsoft SMTP product may seem to be open for relay, even though it is not.

Common tests exist that you can use to test SMTP servers for relay. You can use third-party Web sites and tools, for example:
http://www.abuse.net/relay.html

-and-

http://mail-abuse.net

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

At first, your SMTP server may seem to fail some of these tests, and your Microsoft SMTP product may seem to be open for relay. However, after you examine the server more closely, you see that your Microsoft SMTP product is not open for relay.
CAUSE
Every TO or FROM address in an SMTP protocol conversation contains two parts: the local part (or mailbox), and the domain part. If the domain part (in other words, the part immediately following the at sign [@]) is not specified, the e-mail message is assumed to be local. In fact, some Microsoft SMTP products append the local domain because some users configure their SMTP clients to use only a user name as the e-mail address. By adding the default local domain, the Microsoft server can add what is most likely to be the default to reduce the support cost.

Collapse -

by sgt_shultz In reply to

This behavior occurs because Microsoft SMTP products do not perform a directory lookup before accepting SMTP e-mail messages for delivery. Microsoft SMTP products only check the recipient's domain to see if it is a local or explicitly allowed domain. If the recipient's domain is not a local or allowed domain, the server responds with an error message that is similar to:

550 5.7.1 Relaying prohibited
All that is required to prevent relay is a verification that the domain part of the TO address is local. Checking the mail server's directory to see if the recipient is valid is an option, but is not required. If a mail server accepts a message, and then later decides that it cannot deliver the message, the server must generate a non-delivery report (NDR). (See the Request for Comments [RFC] 2821 document, section 3.7 and the RFC 1123 document, section 5.2.7.) The Microsoft SMTP products comply with this requirement. The Microsoft SMTP server seems to accept the message for relay, but later the server does not deliver the message and generates an NDR.

Collapse -

by sgt_shultz In reply to

MORE INFORMATION
If you must have the ability to perform directory lookups during the SMTP protocol conversation, you can write a Windows 2000 SMTP protocol event sink.

For additional information, see the following MSDN Platform SDK SMTP Server Events Web site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/smtpevt/html/_smtpevt_protocol_event_interfaces.asp

The recommended RFC-compliant response is a response that is similar to:

550 5.1.1 user@northwindtraders.com... User unknown
Microsoft chose not to perform the directory lookups during the SMTP protocol conversation for the following reasons:
If you return a 5xx error to a fake user, a user who is sending bulk, unsolicited commercial e-mail messages (spam or UCE) to your server knows instantly which addresses are real and which are fake. If that user plays a dictionary of names through the SMTP protocol, that user can easily harvest a list of valid e-mail addresses. This may also be a security risk to your local users because user names are often the same as e-mail addresses.
A malicious user can use the FROM address to gain unauthorized access into a system (spoof), and then use the victim's server to send NDRs to the intended recipient. This attack only hits this server with as much data as the attacker sends to it. In other words, if the malicious user wants to send 1 megabyte (MB) of data to a third party, the malicious user must spend 1 MB of his or her own bandwidth to send 1 MB of data to the SMTP server. Typically, such a malicious user tries to send 1 MB of data, but still cause tens or hundreds of MBs of data to hit a victim or set of victims throughout the Internet. The best way to stop this behavior would be to validate FROM addresses across all of the Internet. However, there is no standard to validate FROM addresses across the Internet; therefore, the best way to deal with this behavior is to look at message headers.
If a directory lookup is performed during th

Collapse -

by Choppit In reply to

Thanks for your input. I had read this information and have already determined that the server is indeed being used as a relay. Once I've established why the IMC refuses local but not remote connections I can then stop the relaying and implement AV.

Related Discussions

Related Forums