Mail relays yet relay is looks closed!

[ReddLefty]

I have a client that has the following problem, yet I'm stumped. I need some input from more knowledgable people in EX2k.

- This server is being used as a relay. The relay queue shows constant traffic.


- The server settings for relaying are set as follows:
= I the SMTP Virtual Server Setting Authentication setting are set to Anonymous, Basic and Intergrated Windows account (all Checked ON)
= The connection Control is All except the list below
= The relay is set to 'Only the list below' and the list is blank. The checkmark for "Allow all computers which successfully authenticate to relay .... " is Checked ON.

Somehow, mail is still being relayed. Any clues what to check? Should we remove the Anonymous in the Access Control Authentication Methods?

All input is welcomed.







"In space, nobody can hear you click..."

 

[evildik]

Oh i forgot the queue filling up with all the outgoing queues went away after a SP4 install. However people are still able to relay even though i specifically configure exchange not too do so.

 

[1DonC]

I have resolved this issue many times recently, and have noticed this problem happening more often.
What seems to be happening is even though your Exch2k server is closed for relaying, you still keep getting spammed, a possible cause is that someone has hacked into your system and is using has access to an account on your domain, which its using to authenticate onto your domain and relay using this account using the AuthLogin verb.

If you have ticked the option in the relay restrictions to Allow Authenticated users to Relay regardless of the window above, this will allow them to relay, because they are actually using a valid account.
To prevent this from happening, check that your Guest account isnt enabled, this is the most common account hacked into as it has a blank password by default, if it is, disable it instantly, also if you turn up logging to Max on the Transport service and install Protolog.dll and set logging to 7, you can find out which account is being used to authenticate on the domain with, filter the App and the Sys log for the event id 1708, and you will find out which account is being used, once you do this, change the password of the account, and change all other passwords on all accounts, and delete any accounts that you do not use or recognise. Use hard passwords.

 

[salisb]

Here is a link that may explain what is happening. We use Praetor to kill any NDR to mail-daemon@... and that has stopped this. A weekend ago we sent out 5 NDRs/minute for about 2 days before finding the cause of our busy server on Monday. Since then there have been several small bursts of activity, and another large one with several hundred attempts.

Here's the link:

http://www.cmsconnect.com/Praetor/W...ssage_tests/Thwarting_reverse_NDR_attacks.htm

 

[jduawa]

I have a call into Microsloth, but their wait time was 2 hours, if i find anything out i will post

 

[evildik]

Whew about time someone calls microsquish. Please keep us updated...!

 

[compgirlfhredi]

I have worked around Exchange SMTP relay by allowing relay for authenticated users only. Since no one can authenticate it fails. Some people don't realize that there is also a connector configuration
that could allow relaying. In the properties for the SMTP Connector for the routing group, in the address space tab there's a check box that states: "Allow messages to be relayed to these domains" Since this is a SMTP connector to the "world" (AKA Internet Mail Service), the "these domains" that the check box refer to are basic everything (*). The connector's setting overrides the SMTP Virtual Server settings. So if you don't want to relay, make sure the box is
not checked and that the SMTP Virtual Server is also not allowing relaying. The problem is occurring on upgrades of Exchange 5.x to Exchange 2000, and Exchange 2000 to Exchange 2000 Service Pack 3. Apparently, either of these two upgrades will cause a previously secure version of Exchange to become an open relay that must be manually closed. One person also told us that they were told that the "Exchange 2000 Post-Service Pack 3 (SP3) Rollup Patch 6396.1" was supposed to fix the problem, but they had not tried to find and apply the patch ,and did not know anyone who had used it. I had to put the Exchange Server one hop in, and use a mail gateway to restrict my traffic. Since that was really the best way to do it anyway. One admin has asked that we emphasis this paragraph from the relay.asp article:

"What the Microsoft article and online Help don't spell out is that when you select a routing restriction, you can choose not to enter any IP information. The trick is that you can select the Hosts and clients with these IP addresses check box but not specify any IP addresses. Unless you have a specific need to have your Exchange server relay, don't enter any IP addresses on this page.
This selection changes the rules that the IMS uses when evaluating the SMTP protocol. Instead of letting the IMS accept the RCPT TO specification blindly, this selection causes the IMS to check for local delivery before
letting it upload a message. If the recipient isn't local, the IMS will return 550 Relaying not permitted."

If you are providing SMTP service to a local network, you need to define the local network's IP addresses as "allowed to relay", or local users won't be able to send mail offsite...

SMTPD admins: An admin has reported that they've been detected relaying due to this bug:

http://download.sourceforge.net/mirrors/OpenBSD/src/libexec/smtpd/src/CREDITS

What: Caught Bug where smtpd would treat dn_expand failure in expanding an NS or MX record too seriously - as a syscall failure allowing message. See

http://www.postfix.cs.uu.nl/faq.html#open_relay

and

http://www.postfix.cs.uu.nl/uce.html

McAfee WebShield admins: This software has no effective relay control. Antivirus processing must be placed after your mailserver, not in front of it.

Norton Antivirus for Internet gateways: This software has no effective relay control. Antivirus processing must be placed after your mailserver, not in front of it.
From a mail essentials admin:
Their information regarding open relays is not very clear. However after some trial and error we found that in the configuration
interface in:
server settings,
SMTP options,
advanced SMTP options,

you need to add your local domain with internal IP address in the allow relay from list. This then prevents (hopefully) relaying from any other location and generates the 550 message to the RCPT TO:.

What I use:

http://www.dataenter.co.at/doc/xwall.htm#license

 

[jduawa]

my smtp connector is configured properly (unchecked box) relay is closed but still relays,
we have a pix between the internet and the exchange box and someone suggested that if you are natting port 25 then the exchange server may be seing that telnet session as coming from the inside, hence allowing relaying

 

[evildik]

I thought you called Microsquish? What did they say about this? Its strange because SMTP is configured properly and it still relays... Although I do not see the outgoing queue building up like I did before after i applied SP4

 

[GuillermoOZ]

I finally fixed this problem (it seems, you never know, right?)
Apparently the problem is that one or more passwords were compromised. I have to finally believe this. I couldn't force everybody to change their passwords because many of our users are road warriors, and can't really unilaterally change their passwords without letting them know. So what I did, is, I followed the normal configuration specifications that everybody agrees on, but I also "unchecked" the option "Allow to relay if authenticated regardless of this list". I know, no one can use Outlook or Outlook Express from outside the office, but they can still use OWA in the meantime. This really stopped the relay, and once the queues cleared we went back to normal. Also, try deleting the NDR's first from the queues by applying a filter and choosing postmaster@domain.com and then the action delete. It will take a while but your queued messages will go down quickly. This way you can let the queue be delivered (specially yahoo.com and hotmail.com queues that may have true messages from your users.