Re: Exchange SA and users sending to this account

Tech-Archive recommends: Fix windows errors by optimizing your registry

If I were in your shoes I'd work this with your antispam vendor.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"

"David A" <DavidA@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:62E3B687-9A42-408A-8830-CEBB85A76CFA@xxxxxxxxxxxxxxxx
OK then that fix is not acceptable. Thus, how do you recommend fixing
this
issue without breaking NDR's and thus preventing spammers from doing this
type of process?

"Ed Crowley [MVP]" wrote:

You can do that but the downside I referred to in my response applies.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"

"David A" <DavidA@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:89985AEA-4FFE-4840-99B6-1971BB5DA2AD@xxxxxxxxxxxxxxxx
Odd because I use a SPAM company to prevent such an issue from
occurring.
This only started when we migrated from Exchange 2000 to Exchange 2003.

Would the following be an appropriate fix?

Exchange by default produces a NDR report for every e-mail sent to an
incorrect address. For example is if a person sends an e-mail to
nobody@xxxxxxxxx then the server actually takes the message sees that
it
cannot be delivered then sends an NDR (non delivery report) to the
senders
FROM address telling them that the e-mail address does not exist. Side
affect
of my fix below is that if a spammer is actually using a legitimate
server
he
could check all known common names on your server and figure out some
addresses that actually exist on your server. This is the fix I used to
resolve the problem:

a. Load exchange system manager and then click the + on Global
Settings.
b. Right click on Delivery options and choose Properties.
c. Click on the tab for "Recipient Filtering".
d. I checked the box for "filter recipients that are not in the
directory".
Once this box is checked the server gives you a message that you still
have
to make another setting to complete the process as described in next
step.
e. As a final setting you have to go to the SMTP Virtual Server (also
in
the
exchange system manager under the server) right click on the SMTP
virtual
server and choose Properties. Now go to Advanced for the IP address and
click
EDIT for the IP address (usually unassigned) and you will see a check
box
that says "Apply Recipient Filter". Check that box.
f. Now this will stop the exchange server from taking a message to a
user
that does not exist on your domains (active directory in this case) and
sending NDR reports back to the spammers reducing traffic on the server

Or would you have another recommendation

"Ed Crowley [MVP]" wrote:

These are likely responses to spammers' attempts to send mail with
forged
reply to or from addresses. There's nothing wrong with your
configuration
per se. You could follow the KB article to suppress NDRs, but there's
an
ugly side effect to that in that your legitimate correspondents won't
be
notified if they, say, misspell one of your user's e-mail address.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"

"David A" <DavidA@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F88D45AA-ECBB-4203-A7CA-F70B7A41B1F6@xxxxxxxxxxxxxxxx
Exchange 2003, SP2

I noticed that my local delivery que was getting some message
backup.
When
I opened the message I indicated that users (RANDOM) were sending
e-mails
to
the Exchange System Attendant Account. During the time the messages
were
in
the local que the user would get an e-mail from the postmaster
account
indicating the following:

This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

name of server - SA@xxxxxxxxxxx

Naturally, the users are not sending to this account and the above
message
being sent to users is creating a small amount of havoc.

I have setup logging, did a message trace and still can't figure out
what
is
causing this to occur.

Any ideas?








.

Quantcast