Subject: RE: Asinine anti-spam mechanisms

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Mon, 7 Jun 1999 15:15:42 -0700

It was a stupid coding error - the guys who wrote the SMTP service shipped
in the NT4 option pack used an invalid handle value during a call to an NT
API that was supposed to wait until either a timeout occurred or when the
SMTP service was shut down.

There were actually 2 different bugs which conspired to cause the problem:
	1) The invalid handle in the first place
and	2) The fact that instead of checking for the explicit ERROR_TIMEOUT
error, they decided that ANY error value was caused by a timeout.

There was no INTENTION to violate 1123, it was just a plain and simple screw
up.  And we managed to screw it up because we're human beings and we didn't
have a test case for this particular situation.  And as Dick commented below
- we had a fix available within days of when it was reported (and the fix is
contained in NT4 SP5, which has been on the web for at least a month now).
But it does take time for fixes to be propogated, that's the way life works.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: D. J. Bernstein [mailto:[email-masked]]
> Sent: Monday, June 07, 1999 2:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Asinine anti-spam mechanisms
> 
> 
> Dick St.Peters writes:
> > If the remote client is an NT server running Microsoft SMTP 
> without an
> > update Microsoft issued in March, it will try again 
> immediately if you
> > send it a 4xx code.
> 
> As if common sense weren't enough: RFC 1123 specifically requires that
> SMTP clients delay before trying again. I wonder how Microsoft managed
> to screw this up.
> 
> Anyway, this doesn't justify Keith's asinine ``put the message on hold
> and wait for human intervention'' method of handling 
> temporary failures.
> If Keith has a problem with a Microsoft host, then he can deal with it
> without setting up a fragile mail system that screws up other people's
> messages.
> 
> ---Dan
>

---

From: "David Lemson (Platinum)" <[email-masked]>
Date: Mon, 7 Jun 1999 10:39:58 -0700

I'm sorry I didn't get back to you, David.  We are currently
investigating the fix to this problem.  It turns out that we have a bug,
where if the FIRST RCPT TO: gets a 552, then we mistakenly do not mark
the rest of the accepted recipients as delivered.  Of course, once we do
fix it, we will document the bug in a KB article (as we did with the bug
that Dick refers to below).
I was incorrect in saying that we complied with smptupd-10, as we hadn't
identified the bug in our code at that point.
I am investigating whether or not the bug exists for when the first
recipient gives a 452, and will respond privately to David with the
answer.

David

-----Original Message-----
From: David Mayne [mailto:[email-masked]]
Sent: Sunday, June 06, 1999 8:18 PM
To: Dick St.Peters
Cc: [email-masked]
Subject: Re: Asinine anti-spam mechanisms

Dick St.Peters:
> 
> If the remote client is an NT server running Microsoft SMTP without an
> update Microsoft issued in March, it will try again immediately if you
> send it a 4xx code.  "Immediately" means up to 6 times per second for
> the cases that we've logged here.  The first report of this on bugtraq
> was of a case of an NT server attempting to deliver a message 200,000
> times in one day.

I am glad that you have brought this up, as my previous questions
on [45]52 response codes have been prompted by Microsoft SMTP
MTA mailbombing Mindspring's customers in a very similar
fashion. Mindspring has been using a 552 code for years for
over mailbox full violations, but prior to 6 months ago, this
code was only used by the local delivery agent, and a bounce
sent back  - we now have a policy not to accept mail for users 
who we know are over the quota in the smtp session at the time
of RCPT. The only client that has problems with this is Microsoft's 
SMTP MTA. Microsoft's attack on our customers goes as follows:

MAIL FROM: [email-masked]
250 [email-masked]... Sender ok
RCPT TO: [email-masked]
552 quota violation
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
[...]
250 rlmc41.bs3.37kbi17 Message accepted for delivery
MAIL FROM: [email-masked]
250 [email-masked]... Sender ok       
RCPT TO: [email-masked]
552 quota violation
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok      
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
[...]
250 rlmc88.bs3.37kbi17 Message accepted for delivery

This Microsoft SMTP MTA will continue mailbombing
the recpients who are not over quota until their 
mailboxes fill up to, and all are returning 552 codes
- finally, the attack stops (or our admins notice the
attack, and null route the offending Microsoft SMTP
MTA). In cases, our customers have had over 5000
messages in their mailbox, and are denied service
to getting any more mail.

Keith Moore stated the following concerning 452 and
552 error codes in a recent response to my questions:

>imho, "too many recipients" should always be 452 code.
>the 552 code would normally be interpreted by the sender as  
>"completely stop trying to deliver this message to this recipient"
>which almost certainly isn't correct behavior for a "too many
recipients"
>condition.

and:

>if a client gets a 4xx in response to RCPT, it should treat it as
>a temporary failure to deliver that message to that recipient,
>and it may retry later if it wishes.  if it gets a 5xx in
>response to RCPT it should treat it as a permanent failure
>to deliver the message to the recipient. it should normally
>bounce the message, but it should definitely not make further
>attempts to deliver the message after that.
>
>however, a 452 code in response to RCPT should probably be interpreted
>by the client as "stop trying to send RCPTs in this session" -
>so the client would handle that recipient and all remaining
>recipients for that messages as if they were temporary failures.
>
>I would treat 552 should as a special case and handle it identically
>to 452.

As such, according to what Keith states above, Microsoft should not
be retrying the same sequence of recipients over and over in the
same session with either a 452 or 552 code, which is clearly being
violated by the incident outlined above. My question now, is 452
sufficient for Microsoft to stop mailbombing other recipients when
one of the recipients in the list happens to be over their quota,
given the fact that 4xx codes have also proved to be problematical
with Microsoft's SMTP MTA in the past. I have no problems changing
to a 452 code if this solves the problem, and spares our customers
the grief that they have been experiencing from this problem.

> 
> We had cases involving tens of thousands of attempts in our own logs
> but had attributed them to intentional denial of service attacks on
> our mail servers.  They stopped happening when we began returning 5xx
> error codes.
> 
> That, BTW, was Microsoft's suggestion too.

Well, see above, 552 is troublesome for us, at least on RCPT.

> 
> (To Microsoft's credit, they promptly acknowledged the problem and
> fixed it - but there are lots of NT systems out there that have not
> had the update applied.)

The mailbombing incidents Mindspring has been experiencing have 
not an everyday occurence, and we receive millions of messages
per day, so the sequence above was somewhat hard to track down.
Once we did so, I contacted David Lemson, SMTP Program Manager
for Microsoft, and presented him with evidence from our logs of 
the above problems.  He responded that he got the developers to look 
into the issue, and then replied, stating that "We believe our
servers are doing the appropriate thing." He then made an appeal
to the drums-10 draft, and stated "we are abiding by the suggestion 
that they give (we treat a 552 as if it were a 452)."

If this is how Microsoft treats a 452 code (i.e., continuing
issuing RCPT's and DATA over and over again to the same list
of recipients), then I'm wondering what good it will do for
us to change to a 452 code for quota violations on RCPT.
We could return a 550 code (troublesome because sendmail will
send out a bounce with the subject stating "User unkown", 
which is a problem for our support department) to stop our
customers from being bombed, or perhaps some other 4xx code
- but, how will Microsoft SMTP server respond to any other
4xx codes on RCPT ? Clearly, even if we are not returning 
the appropriate code for quota violations (552), the behavior 
of their MTA under these circumstances is still inappropriate 
according to my reading of updt-10 and Keith's observations 
noted above. 

In light of the above issues, does anyone have any suggestions
on how to deal with Microsoft's SMTP MTA, since Microsoft
does not think this is a problem ? My purpose here is not
to grill MS, but to stop our customers from being unfairly
bombed by MS's MTA. We have *never* had this issue with any
other MTA's - sendmail, qmail, postfix, etc will not repeat
the same delivery sequence over and over again when getting
a 552 code on RCPT. 

I have responded privately to David Lemson at Microsoft,
disputing their contentions that their SMTP MTA is behaving
appropriately according to drums-updt-10, but have not 
recevied any response in over a week, hence my sharing this
issue with the drums list.

Thanks,

David
[email-masked]