Re: MS Exchange 5.5 NDRs (from MyDoom)
From: Darryl J Roberts (DarrylJR_at_SEU.COM)
Date: 02/05/04
- Previous message: Manskopf, Michael: "Outlook 2003 and OWA on Exchange 5.5 Bug"
- Maybe in reply to: Darryl J Roberts: "MS Exchange 5.5 NDRs (from MyDoom)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 4 Feb 2004 16:46:09 -0800 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Thanks to all who responded to me privately about the problem of
Microsoft Exchange 5.5 sending so many NDRs that it is causing network
congestion.
Several people responded with suggestions on how to fix (or detour) the
problem. I'll summarize those suggestions below.
A few people suggested that what I was asking for would violate the RFC
for SMTP or gave suggestions on how unknown users can be handled
(according to the RFC) without sending NDRs. I'll summarize what the
RFC requires, how the change request could be a violation of the RFC,
and how it can be implemented to comply with the RFC below.
A few people contacted Microsoft to say that they are experiencing the
same problem and requested the ability to disable NDR to the Internet in
Microsoft Exchange Server 5.5.
A Microsoft Product Support Services manager called me this morning to
explain that Microsoft will not be making a design change to the legacy
product. I'll summarize Microsoft's position on this fix request below.
Not only are the large number of NDRs caused by the MyDoom worm a
problem, but Reverse NDR spam attacks (see
http://www.cmsconnect.com/Praetor/RNDR/prRNDR.htm) is also a problem
that cannot easily be dealt with in Microsoft Exchange 5.5. NDRs sent
to domains without a properly configured MX server can set in the SMTP
outbound queue for 3 days, creating a big backlog in the outbound queue,
so big that other problems can happen.
Unfortunately, IMO mass mailing worms and spammers have made NDRs almost
useless by causing so many illegitimate NDRs that people will no longer
pay attention to NDRs.
Work arounds
============
Upgrade from Exchange 5.5
-------------------------
The first suggested fix is to upgrade to Microsoft Exchange 200x. This
was the first suggestion from Microsoft. Migrating from Windows NT 4
and Exchange 5.5 requires implementing Windows 200x Active Directory,
which is a non-trivial change. It is not something that is going to
happen over night. I realize that Windows NT 4 and Exchange Server 5.5
are no longer in mainstream support, but there are still a lot of
customers using these products. We support several small businesses (6
to 50 users) that just do not have the budget to upgrade to Windows
200x/Exchange 200x right now.
Exchange 200x does have the ability to disable NDRs (see MS KB 294757).
I am not sure how that configuration change is carried out in the SMTP
protocol. Does this setting cause Exchange 200x to respond to a RCPT
command with an unknown To: address with a 550 error? Or does Exchange
200x accept the message and then just not send an NDR? Also, Exchange
2000 has a "Accept messages without notifying sender of filtering"
option that does accept messages and not send a NDR (see MS KB 276321).
I really wonder if the argument about violating the RFC holds up if
Exchange 200x can disable NDRs.
Front-end Filter
----------------
Install some other SMTP server (that can handle NDRs as we require) as a
front-end to the Exchange Server 5.5 server. This font-end server might
be provided by a service provider. One person is using an MTA
configured to perform an LDAP lookup on the recipient address and reject
the message if it isn't a valid email address.
Bitbucket Recipient for Unknown Addresses
-----------------------------------------
If the unknown recipient addresses are predictable, you can prevent an
NDR by add the bogus recipient addresses into a bitbucket
mailbox--actually a Distribution List with NO MEMBERS and an
additional SMTP addresses for the DL--(see
http://assp.sourceforge.net/fom/cache/76.html for details). This works
best for addresses such as former employees and not the randomly
generated addresses of the MyDoom worm.
Filter to Drop Messages
-----------------------
A filter (event sync) to detect a MyDoom message and drop it before
accepting the message (see http://www.vamsoft.com/orf/tools.asp#novarg)
could reduce the traffic to send an NDR when the recipient of the
message does not exist. Unfortunately, I think that a tool like this
requires Exchange 2000 or later (or the IIS 5.0 or later SMTP service).
NDRs and the SMTP RFC
=====================
RFC 821 (SMTP protocol) requires that if a mail server accepts mail and
then later discovers it cannot deliver the mail, it MUST send an
"undeliverable mail" notification message (NDR). Such messages SHOULD
be sent with a null return address to prevent looping of NDR
messages--yet more unnecessary mail traffic--(a lot of them are not sent
that way and we end up sending an NDR message for NDRs sent to us
because of a spoofed return addresses in the worm-generated message).
Another way to handle an unknown recipient address is during the RCPT
command to verify the recipient and if unknown return a 550 error. (It
is then up to the originating MTA to send an NDR to the client.) This
has the advantage that the original message is not
transmitted/processed/stored and an NDR message does not have to be
sent, reducing network bandwidth by two messages. However, the time to
validate the user might slow down the transfer of messages.
Enabling 550 response to unknown users might enable an SMTP AUTH relay
attack (see http://www.vamsoft.com/orf/authattack.asp).
It appears that Exchange 5.5 only validates the domain part of the
recipient address in a RCPT command.
Microsoft PSS Response
======================
Microsoft Product Support Services (PSS) initially responded that
Exchange 5.5 is in the extended support phase and no non-security fixes
are made to products in this phase.
Microsoft PSS also responded that the requested fix cannot be
implemented because sending Non Delivery Reports follows the RFC.
After going through an escalation process, Microsoft PSS responded that
they took the case to development and it would require a design change
to implement. Microsoft declined to make a design change in this legacy
product.
Darryl J. Roberts, MCSE, MCP+I, CompTIA CTT+, CSSA
Software Engineering Unlimited, Microsoft Certified Partner
PO Box 6476, Ventura, CA, USA 93006-6476
tel. 1-805-650-6030, fax 1-805-650-1835
-----
NTBugtraq Editor's Note:
Most viruses these days use spoofed email addresses. As such, using an Anti-Virus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered.
-----
- Previous message: Manskopf, Michael: "Outlook 2003 and OWA on Exchange 5.5 Bug"
- Maybe in reply to: Darryl J Roberts: "MS Exchange 5.5 NDRs (from MyDoom)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
