Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ISA 2004/SBS 2003 different servers exchange open relay

1 view
Skip to first unread message

news.microsoft.com

unread,
Apr 12, 2006, 5:25:01 PM4/12/06
to
Hi All,

I'm hoping someone can help me out here.

I have an SBS 2003 server on my internal network behind an ISA 2004
firewall.

Previously my company was using a POP3 connector to recieve external email.
I'm now implementing external MX records and pushing email directly to our
internal SBS/exchange server. What I have done is quite simple, created MX
record, publish mail server SMTP to internal SBS through ISA, started
receiving email.

The problem I'm having is that this morning I had over 60000 emails in our
SMTP queue. I did a bit of poking around and found this article,
http://support.microsoft.com/kb/324958/en-us, and followed it but the
exchange server is still showing up as an open relay.

I really want to move these guys off of the POP3 server they are using now
for external email so I'd appreciate any ideas/thoughts anyone might have.

TIA,

Mike


ahl

unread,
Apr 12, 2006, 11:10:33 PM4/12/06
to
Check that you are forwarding 'originating IP' in the ISA publishing rule.

Check the SBS servers SMTP logs for what SBS is recording as the source IP
for the transactions.

Check what 'relay restrictions' are set on the SBS SMTP server.

"news.microsoft.com" <mka...@hotmail.com> wrote in message
news:umWaPen...@TK2MSFTNGP02.phx.gbl...

Crina Li

unread,
Apr 13, 2006, 4:26:54 AM4/13/06
to
Hi Mike

Thank you for posting in SBS newsgroup.

From the description, I found you have published the SMTP server using ISA
2004? If so, do you have followed the steps of KB 324958 to disable or
delete the SMTP Server Publishing Rule in ISA server? If not, the server
will still be an open relay. Also please check if 127.0.0.1 is in the list
of IP addresses that are allowed to relay in the properties of the default
SMTP Virtual Server because it will be added back after you run CEICW.

As the KB states, the server may be an open relay if the following
conditions are true:

o ISA Server is configured with a server publishing rule for the SMTP
protocol.
o 127.0.0.1 is in the list of IP addresses that are allowed to relay in the
properties of the default SMTP Virtual Server.

If you have followed the KB 324958 closely, would you please help me
collect the following information?

1. The external IP of SBS and the external SMTP domain name.
2. Are these emails NDR emails? If so, please check the following:

(Do NOT use these steps unless you are under this kind of attack) Nowadays
spammers have a new means to avoid filters built into many systems. They
take advantage of a mail systems sending of a non-delivery report (NDR)
when a message cannot be delivered as addressed and returns the original
contents. Since this follows the RFC standard, most all mail servers will
function this way. This is what is called a "Reverse NDR attack" (RNDR).
This form of attack is becoming increasingly widespread. Some users get it
so badly that over 33% of their Internet messages are attributed to this
type of spam. The end result is the spammer has attained a new form of mail
relaying. Your server''s resources are being stolen to deliver spam.

How does a "Reverse NDR" attack work?

Step 1 Spam email is created with the intended spam victim''s address in
the sender field and a random, fictitious recipient, at your domain, in the
To: field.

Step 2 Your mail server cannot deliver the message and sends an NDR email
back to what appears to be the sender of the original message, the spam
victim.

Step 3 The return email carries the non-delivery report and possibly the
original spam message. Thinking it is email they sent, the spam victim
reads the NDR and the included spam.

What are the symptoms of a RNDR attack?

1. Sluggish email delivery
2. Outbound queues full of non-delivery notices
3. Excessive admin time to clear outbound queues
4. Badmail folder''s size grows quickly

If you are experiencing any of the above, chances are good your mail server
is under attack.

To stop the RNDR from happening, follow the following steps:

To Configure Recipient Filtering

When you enable recipient filtering (if you are using SMTP for incoming
emails) on the SMTP virtual server, e-mail messages that are received from
anyone on the recipient filter are not accepted. Recipient filtering is
set globally, but you enable it on a per-Virtual Server basis on each SMTP
virtual server.

To create a recipient filter:

1. Click "Start", point to "Programs", point to "Microsoft Exchange", and
then click "System Manager".
2. Expand "Global Settings", right-click "Message Delivery", and then click
"Properties".
3. Click the "Recipient Filtering" tab, and then click the checkbox at the
bottom (Filter recipients who are not in the directory).
4. Specify any additional filter options that you want to configure,
Select Apply, and then click "OK".

To enable recipient filtering on the SMTP virtual server:

1. Click "Start", point to "Programs", point to "Microsoft Exchange", and
then click "System Manager".
2. Expand "Servers", expand "<ServerName>", and then expand "Protocols".
3. Expand "SMTP", right-click "Default SMTP Virtual Server", and then click
"Properties".
4. Click the "General" tab, and then click "Advanced".
5. In the "Address" list, click the IP address where you want to apply the
recipient filter, and then click "Edit".
6. Click to select the "Apply Recipient Filter" check box, click "OK", and
then click "OK".

Note: Recipient filter rules apply only to anonymous connections.
Authenticated users and Exchange servers bypass these validations.

Also I provide the following methods of protecting Exchange:

1. Disable the Guest account in your SBS 2003 server and enable Stronge
Password Protection. Everytime when you run CEICW you will be asked for
enabling password policies after it ends. I suggest you enable it. You can
also do that in Server Management\Users->Configure Password Policies. For
more information, see:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/
security/bpactlck.mspx

2. We can block unsafe attachments in emails by running through CEICW and
enable Internet Email on the wizard. You should see a page named "Remove
E-mail Attachments" where you can choose to block all or some of the unsafe
attachments. For more information, you can search "Remove E-mail
Attachments" (without the quotes) in SBS 2003 Help and Support Center.

3. If you are using SMTP for incoming emails, you can install IMF
(Intelligent Message Filter):

http://www.microsoft.com/downloads/details.aspx?FamilyId=C1B08F7B-8CAF-4147-
B074-8C9C8F277071&displaylang=en

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/imfdeploy
.mspx

Please feel free to let me know if you have any further questions or
concerns.

I appreciate your time and look forward to hearing from you.

Best regards,

Crina Li (MSFT)

Microsoft CSS Online Newsgroup Support

Get Secure! - www.microsoft.com/security

=====================================================
This newsgroup only focuses on SBS technical issues. If you have issues
regarding other Microsoft products, you'd better post in the corresponding
newsgroups so that they can be resolved in an efficient and timely manner.
You can locate the newsgroup here:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx

When opening a new thread via the web interface, we recommend you check the
"Notify me of replies" box to receive e-mail notifications when there are
any updates in your thread. When responding to posts via your newsreader,
please "Reply to Group" so that others may learn and benefit from your
issue.

Microsoft engineers can only focus on one issue per thread. Although we
provide other information for your reference, we recommend you post
different incidents in different threads to keep the thread clean. In doing
so, it will ensure your issues are resolved in a timely manner.

For urgent issues, you may want to contact Microsoft CSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

Any input or comments in this thread are highly appreciated.

=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "news.microsoft.com" <mka...@hotmail.com>
| Subject: ISA 2004/SBS 2003 different servers exchange open relay
| Date: Wed, 12 Apr 2006 14:25:01 -0700
| | Newsgroups: microsoft.public.windows.server.sbs

Mike

unread,
Apr 13, 2006, 12:05:19 PM4/13/06
to
Hi Crina,

Thank you for your response.

Let me see if I can answer some of your questions.

I did follow KB324958 except for the ISA server publishing rule. The thing
that confuses me is that if we don't have this server publishing rule, how
do we receive external emails to our internal exchange server?


I think I have found a fix for this though, our initial settings for relay
properties had our entire internal subnet. What I did was remove this
internal subnet and then add our internal domain name.


Do you see this as a viable fix or should I be configuring it a different
way?


Thank you for your time J

""Crina Li"" <v-cr...@online.microsoft.com> wrote in message
news:XBnbHQtX...@TK2MSFTNGXA01.phx.gbl...

ahl

unread,
Apr 14, 2006, 1:08:29 AM4/14/06
to
Mike,

If I understand your situation correctly, you have a separate ISA server as
an edge firewall. If yes, you will need the SMTP publishing rule to publish
your SBS SMTP.

If you have integrated ISA, i.e. SBS premium, creating an SMTP publishing
rule you will set your SBS premium server up to allow anonymous relay. You
must use the method the connect to internet wizard sets up.

The possibilities are;

Your SBS server is interpreting the relay as coming from a trusted source -
your ISA server.

Check your SBS SMTP logs to see what SBS is recording as the source address
of the offending relay attempts. Check that you have the ISA SMTP publishing
rule set to forward the originating IP.

Try excluding your ISA server from having relay permissions on your SBS SMTP
using subnet masks rather than having the overhead of having to resolve the
domain name each time.

If you are experiencing an NDR attack, I'd suggest disabling NDR and
enabling recipient filtering against AD for incoming mail.

Regards,
Steven B.


"Mike" <mka...@hotmail.com> wrote in message
news:%237RgRQx...@TK2MSFTNGP03.phx.gbl...

Crina Li

unread,
Apr 17, 2006, 12:52:32 AM4/17/06
to
Hi Mike,

Thanks for your update.

I am sorry for the delayed response due to my sick leave and weekend.
Please understand that the newsgroups are staffed weekdays by Microsoft
Support professionals to answer your systems and applications questions.
Your understanding is greatly appreciated!

As I know, if you have ISA 2004 installed on SBS with Exchange, you do not
need to publish the Exchange server because Exchange listens on the
external NIC of SBS and you only need to run CEICW to configure it. If you
have a separated ISA 2004 before SBS with Exchange, you may need to publish
the Exchange server using Server Publishing.

To narrow down your problem, would you please help me collect the following
information?

1. Do you mean you are doing as following and the issue disappears?

1) Right click Default SMTP virtual Server and select Properties.
2) Click Access tab and then click Relay on Relay Restrictions column.
3) Select Only the list below and then remove internal subnet and add
internal domain name.
4) If so, the default setting should be the internal subnet, 127.0.0.1 and
the external IP of SBS.
5) Do you select Allow all computers which successfully authenticate to
relay, regardless of the list above?

2. Please help me confirm the detailed network diagram. Do you have ISA
installed on SBS and how many NICs your SBS has?
3. Are these emails sent by internal clients? Can you send a screen shot to
me?
4. Would you please send your external IP of SBS and the external SMTP
domain name to me and so that we can do some test to isolate the issue?

Best regards,

Crina Li (MSFT)

Get Secure! - www.microsoft.com/security

=====================================================

| From: "Mike" <mka...@hotmail.com>
| References: <umWaPen...@TK2MSFTNGP02.phx.gbl>
<XBnbHQtX...@TK2MSFTNGXA01.phx.gbl>
| Subject: Re: ISA 2004/SBS 2003 different servers exchange open relay
| Date: Thu, 13 Apr 2006 09:05:19 -0700
| Lines: 238
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
| X-RFC2646: Format=Flowed; Original
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
| Message-ID: <#7RgRQxX...@TK2MSFTNGP03.phx.gbl>
| Newsgroups: microsoft.public.windows.server.sbs
| NNTP-Posting-Host: h209-139-216-9.gtcust.grouptelecom.net 209.139.216.9
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTNGP03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.server.sbs:260200
| X-Tomcat-NG: microsoft.public.windows.server.sbs

Crina Li

unread,
Apr 19, 2006, 5:51:18 AM4/19/06
to
Hi Mike,

Thanks for your update.

I have done some tests to your SMTP domain and the Exchange sever is not
open relay now actually. However I am still doing further research on why
it will not be open relay if you set the internal domain name on Relay
Restriction, however the Exchange server will become an open replay if you
set the internal subnet. I will reply you as soon as possible.

Thanks for your time and understanding.

Best regards,

Crina Li (MSFT)

Get Secure! - www.microsoft.com/security

=====================================================

| From: "Mike" <mka...@hotmail.com>
| References: <umWaPen...@TK2MSFTNGP02.phx.gbl>
<XBnbHQtX...@TK2MSFTNGXA01.phx.gbl>
| Subject: Re: ISA 2004/SBS 2003 different servers exchange open relay
| Date: Thu, 13 Apr 2006 09:05:19 -0700
| Lines: 238
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
| X-RFC2646: Format=Flowed; Original
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
| Message-ID: <#7RgRQxX...@TK2MSFTNGP03.phx.gbl>
| Newsgroups: microsoft.public.windows.server.sbs
| NNTP-Posting-Host: h209-139-216-9.gtcust.grouptelecom.net 209.139.216.9
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTNGP03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.server.sbs:260200
| X-Tomcat-NG: microsoft.public.windows.server.sbs
|

Crina Li

unread,
Apr 19, 2006, 11:01:34 PM4/19/06
to
Hi Mike,

Thanks for your time and patient on the issue.

To narrow down the problem, would you please help me confirm if you have
configured ISA Server 2004 server publishing rule to change the source IP
to that of the ISA server?

For detailed information, you can refer to the following KB article:
http://support.microsoft.com/Default.aspx?kbid=838112

If the source IP is being changed to the internal network, this could be
why Exchange to then appear to be an open relay. The source IP address will
need to remain as the original client's IP address.

Best regards,

Crina Li (MSFT)

Get Secure! - www.microsoft.com/security

=====================================================

| Lines: 26


| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2869

| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869

| X-RFC2646: Format=Flowed; Original
| Message-ID: <umWaPen...@TK2MSFTNGP02.phx.gbl>


| Newsgroups: microsoft.public.windows.server.sbs
| NNTP-Posting-Host: h209-139-216-9.gtcust.grouptelecom.net 209.139.216.9

| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTNGP02.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.server.sbs:259980
| X-Tomcat-NG: microsoft.public.windows.server.sbs

Crina Li

unread,
Apr 20, 2006, 10:19:23 PM4/20/06
to
Hi Mike,

Thanks for your update.

I am glad to hear the problem is resolved.

It is my pleasure to work with you in this post. Do you have any questions
or concerns regarding the issue? If so, please do not hesitate to let me
know. We are glad to be of the assistance.

Again, thank you for using Microsoft newsgroup. Have a nice day. :)

Best regards,

Crina Li (MSFT)

Get Secure! - www.microsoft.com/security

=====================================================

0 new messages