iis smtp nntp: Right from teh box, if a user fails to authenticate, SMTP accepts teh
message from teh user but doesn't send it. This creates excessive
traffic to teh server when a compromised userid/password has been
corrected--the spammers think the spam is continuing OK, and keep
sending it.

Anyone know of a way to have SMTP tell the user that they didn't
authenticate properly?

[quoted text, click to view]

Not if correctly configured. A 550 error will be returned if the
recipient domain is not allowed for relay, and any subsequent DATA command
will be discarded.

What settings have you used to lock down relaying?

--Sandy



------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.

On Mon, 14 Apr 2008 12:17:03 -0400, "Sanford Whiteman"
[quoted text, click to view]

The standard recommended settings:

Authentication

Annonymous (so we can receive emails from other SMTP server)
Basic (most users)
Integrated Windows Authentication (some users use this)


Relay:

* Only list below (list is empty)

Allow Authenticated computers to relay. (and as we know, an anonymous
users is not an authenticated user...)

Note:

The spammer can't send emails, they don't get relayed, but the sender
is never notified that the attempt fails. There was logic behind that
(it allowed SMTP to mask a userid/password attack, since it never told
that the user's attempt failed!) But now we see the problem that the
spammer connects with bad credentials, and is able to drop his message
to the SMPT server. That ties up bandwidth, and wastes our resources.

I tried an experiment: I blocked the spammer's IP address at the
firewall, and that resulted in the spammer moving to another IP
address. This attack is a botnet for sure, with a controller somewhere
that is telling each bot which SMTP server to try to use. When a bot
finds it cannot access a given server the controller gives that
server's address and info to another bot in an attempt to continue the
spam attack.

[quoted text, click to view]

The *only* reason you should be accepting e-mail that you know you'll
never deliver -- especially, as in your case, if you do this by
running an apparently open relay for domains you don't even service --
is if you are running a honeypot and require a corpus of known spam to
build blacklists for your _real_ mailflow.

Mail admins usually learn the hard way that any tactics that increase
the use of your resources -- tarpitting, fake acceptance, etc. -- make
you the ultimate loser in the situation. The other side has all the
toys. If you have unlimited bandwidth and scaleability, maybe you can
get away with trying that spam-laboratory stuff.

[quoted text, click to view]

Yep, so turn off whatever you've done to allow that to happen.

--Sandy


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.

On Wed, 16 Apr 2008 00:11:02 -0400, "Sanford Whiteman"
[quoted text, click to view]

Well, that's not a terribly useful suggestion since this is how IIS
SMTP is built by MSFT. I *WANT* to turn it off, and that is what I
asked, so saying 'Turn off whatever' doesn't help me.

[quoted text, click to view]

No, it's not!

If a session is not allowed to relay to a domain -- because it is not
authenticated via ESMTP AUTH and does not come from pre-authenticated
IP address -- it _will not be allowed to submit mail_ to that domain.

[quoted text, click to view]

I don't know so far. You've said it was done purposely, which I
presumed meant _you_ were using a tweaked setup (false open relay and
bit-bucket event sink, for example) that you wanted to tweak further.
Now I understand that you thought you had a plain-vanilla setup. I can
assure you that you don't.

Can you post a log of the server accepting mail for a destination
domain you don't relay for?

--Sandy




------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.

On Thu, 17 Apr 2008 14:53:35 -0400, "Sanford Whiteman"
[quoted text, click to view]

You are talking apples, I"m talking oranges.

A user comes into my SMTP server, using a userid and password. The
userid/password is no longer valid (it was at one time, but not
anymore).

The spammers still come to the SMTP server, and (attempt) to send
emails. The SMTP server accepts the emails, then bit-buckets them.

I don't recall saying "a destination domain you don't relay for?" so
that may be where we're getting confused.

[quoted text, click to view]

That's incorrect. If your session is not authenticated via (valid)
SMTP AUTH credentials or because your session is coming from a
pre-authenticated source IP, IIS will only accept messages for domains
_for which it does not require authentication_. You cannot submit mail
for domains that require authentication before relaying.

That is what "requiring authentication" means, and it occurs during
the original SMTP submission attempt. There is no post-acceptance,
pre-delivery bit-bucketing; IIS SMTP has no such feature. If a message
does get accepted for delivery, it's not a fakeout: it means
authentication was not required for delivery to the recipient domain,
and delivery will indeed be attempted to the recipient domain. If the
recipient turns out to be unreachable, _and the sender is also
unreachable_ for a bounce notification, then mail will be placed in
\Badmail. That is not the same as simply bit-bucketing the original
message. It's the result of a double-bounce.

Don't know what could be leading you to believe that the
authenticated/unauthenticated state is interpreted after submission,
as opposed to during the attempt to submit. True, that state can be
made available to other (3rd-party) anti-spam programs that may
process mail after acceptance and take corresponding action (such as
whitelisting authenticated submissions), but that's not what we're
talking about.

--Sandy


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.