none
Exchange is NOT an open SMTP relay BUT!

    Question

  • Have a customer for which I just rebuilt their SBS 2003 box.  Applied all service packs for SBS and Exchange.  Using the instructions in KB324958 I confirmed it is not an open SMTP relay.  Telent responded with 550 5.7.1 Unable to relay for user@mydomain.com.  I am not seeing event ID 1701 as KB324958 suggests I might so I assume no one has cracked a users password.  Never the less I have over 1600 queues with mail in them in the Default Virtual SMTP Server.  I also have toms of event ID 7002 and 7004 in the application event log.  I know our IP is on some blacklists.  Also under the Default Virtual SMTP Server in Current Sessions I have a public IP address, that is not ours, listed 7 or 8 times with short connection times.  The server is behind a SonicWALL TZ200 with only ports 25 and 110 open inbound.  POP has not been configured in Exchange.  The server and workstations have been scanned for malware.  I am stumpted.

    John

    Additionally I reconfigured the Default Virtual SMTP Servers Relay Restrictions.  Only the list below is now empty. Allow all computers which successfully authenticate to relay... IS checked.
    • Edited by johnfds Thursday, January 23, 2014 6:25 PM
    Thursday, January 23, 2014 6:10 PM

Answers

  • Ran the kaspersky virus removal tool. 

    The queues are no longer appearing.

    I am pretty sure the we are not sending spam currently because we are only on 3 blacklists.  One is in Germany.  One is SORBS Spam but there site indicates the last spam was seen on the 5th. The last is ivmSIP out of Macon, Georgia.  We were on 4 yesterday.

    I have not as yet utilized the SonicWALL.

    Monday, January 27, 2014 7:12 PM
  • Every time a server is trying to send email to your organization, it will open a SMTP connection. That's what you are seeing, and it's completely normal.

    If you see many connections from one IP for a longer period of time, that's probably a spamming sender trying to relay through your server or doing a directory harvest/NDR spam attack. There is no way you can prevent it from happening, but as long as you reject those attempts (as you now should be doing), it's nothing to worry about.

    You can check if you find that particular IP in your event logs to find out what's going on.


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Monday, January 27, 2014 7:19 PM

All replies

  • That sounds like a directory harvest attack. See http://support.microsoft.com/kb/899492

    The mail queues you are seeing are NDR's (Non Delivery Report) sent by your server. By enabling recipient filtering, NDR's are not generated but harvesting is blocked in the SMTP protocol level instead.

    BTW, just a kind reminder that Exchange 2003 support will end in April. Your customer would probably appreciate a newer server solution.


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Thursday, January 23, 2014 10:55 PM
  • The link is no good.  Really do not want to turn off NDR notifications.  Anyone got any ideas how / these messages are getting sent from the server?
    Friday, January 24, 2014 5:06 PM
  • What you mean it's no good? Works for me. If not, you can Bing the KB 899492.

    You are not turning off NDR's, only rejecting spam and preventing your server sending NDR's to spammers' bogus addresses. Any message from a valid source will get delivered or returned with NDR.

    Trust me, you DO want to check that recipient validation is on. It may or may not solve your issue, but you DO want to turn it on if it isn't already.

    If it doesn't solve your issue, we can help you to troubleshoot it further, but that's where you need to start. Believe it or not.


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)


    Friday, January 24, 2014 8:49 PM
  • A better explanation of the connection filtering (including Recipient filtering) can be found at http://support.microsoft.com/kb/823866/


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Friday, January 24, 2014 8:55 PM
  • Ok Message Delivery Properties, Recipient Filtering tab, "Filter recipients who are not in the Directory" IS checked.  Is this what you are looking for?

    John

    Friday, January 24, 2014 11:56 PM
  • OK, good. Is it enabled too? Please check:

    Start Exchange System Manager.

    • Expand Servers, expand <var>Server Name</var>, expand Protocols, and then expand SMTP.
    • Right-click the SMTP virtual server where you want to apply the filter, and then click Properties.
    • On the General tab, click Advanced.
    • Click the IP address that you want to apply the filter to, and then click Edit.
    • In the Identification dialog box, click to select the Apply Recipient Filter check box.
    • Click OK, click OK, click Apply, and then click OK.
    • Restart the SMTP virtual server where you applied the filter.


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Saturday, January 25, 2014 12:20 AM
  • Yes, Apply Recipient Filter IS checked.
    Saturday, January 25, 2014 12:23 AM
  • Very good, then the NDR spamming is ruled out. Then we would need to investigate those Event ID 7002 an 7004's. Do the recipients look like valid? Could you post a few examples?

    Is the inbound mail flowing normally? Are you able to get any outbound mail through?

    Since the IP is on some blacklists, would it be possible for you to use the ISP relay as a smart host for sending?


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Saturday, January 25, 2014 8:52 AM
  • Inound mail is working.  Outbound works for some and not for others I believe due to the blacklists.  See the sample event sent to a yahoo subscriber.  Not getting any 7004 events since around 9 am on the 24th.  Now getting lots of 7010.

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: SMTP Protocol
    Event ID: 7004
    Date:  1/24/2014
    Time:  8:58:21 AM
    User:  N/A
    Computer: SERVER
    Description:
    This is an SMTP protocol error log for virtual server ID 1, connection #2690. The remote host "128.163.184.108", responded to the SMTP command "rcpt" with "550 5.1.1 User unknown  ". The full command sent was "RCPT TO:<zxie1@uky.edu>  ".  This will probably cause the connection to fail.

    Event Type: Warning
    Event Source: MSExchangeTransport
    Event Category: SMTP Protocol
    Event ID: 7002
    Date:  1/25/2014
    Time:  7:46:32 AM
    User:  N/A
    Computer: SERVER
    Description:
    This is an SMTP protocol warning log for virtual server ID 1, connection #4098. The remote host "98.136.217.192", responded to the SMTP command "mail" with "421 4.7.1 [TS03] All messages from 74.62.198.234 will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html  ". The full command sent was "MAIL FROM:<Judy@wvpmg.com> SIZE=1183  ".  This may cause the connection to fail.

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: SMTP Protocol
    Event ID: 7010
    Date:  1/25/2014
    Time:  7:45:16 AM
    User:  N/A
    Computer: SERVER
    Description:
    This is an SMTP protocol log for virtual server ID 1, connection #4094. The client at "41.203.69.6" sent a "rcpt" command, and the SMTP server responded with "550 5.7.1 Unable to relay for arravillia@centurytel.net  ". The full command sent was "rcpt TO:<arravillia@centurytel.net>".  This will probably cause the connection to fail.

    Saturday, January 25, 2014 4:04 PM
  • That 7004 is either a legit mail sent to a wrong address (user unknown) or a relayed spam. If you haven't seen those 7004's anymore, I guess you had the relay open and have now shut it off, as you told.

    7002 is because your IP is on a blacklist, probably since you had the relay open.

    7010's are inbound messages that are trying to relay through your system. As you see them now, it confirms that you have shut down the open relay.

    At this point I'm no longer sure what was your original problem, and it is practically impossible to debug and help to configure the whole Exchange SMTP in these forums. Could you please elaborate a bit what is your major concern currently, and where you would need help?


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Monday, January 27, 2014 1:58 AM
  • What scanners have you ran on the client side? If you disconnect the rest of the network and freeze and delete the queues, do they still fill up?

    BTW.. Tero Leskinen, is correct that support for most features of SBS 2003 end in April. I have moved all of my clients to either SBS 2011 or another solution. Rumors around the blogosphere are that hacks and exploits will flood at the end of April when Support for SBS 2003 and XP end, so fixing this issue may be a little futile in the short future.


    You can also setup logging in the sonicwall to log traffic from clients to SBS box. I found a rogue workstation at a clients by using this method. It identified the bad unit within a couple of hours.
    • Edited by HCI3 Monday, January 27, 2014 2:08 AM
    Monday, January 27, 2014 2:06 AM
  • The one question I still have is how are the Current Sessions being made to the Default Virtual SMTP server.  Right now I have 3 all same IP address.  Or is this normal?
    Monday, January 27, 2014 7:05 PM
  • Ran the kaspersky virus removal tool. 

    The queues are no longer appearing.

    I am pretty sure the we are not sending spam currently because we are only on 3 blacklists.  One is in Germany.  One is SORBS Spam but there site indicates the last spam was seen on the 5th. The last is ivmSIP out of Macon, Georgia.  We were on 4 yesterday.

    I have not as yet utilized the SonicWALL.

    Monday, January 27, 2014 7:12 PM
  • Every time a server is trying to send email to your organization, it will open a SMTP connection. That's what you are seeing, and it's completely normal.

    If you see many connections from one IP for a longer period of time, that's probably a spamming sender trying to relay through your server or doing a directory harvest/NDR spam attack. There is no way you can prevent it from happening, but as long as you reject those attempts (as you now should be doing), it's nothing to worry about.

    You can check if you find that particular IP in your event logs to find out what's going on.


    Tero Leskinen - MVP (Windows Server for Small and Medium Business / SBS)

    Monday, January 27, 2014 7:19 PM