On 11/04/2020 21:33, Grant Taylor wrote:
On 4/11/20 2:08 PM, antlists wrote:
Okay, it was a long time ago, and it was MS-Mail (Exchange's
predecessor, for those who can remember back that far), but I had an
argument with my boss. He was well annoyed with our ISP for complying
with RFC's because they switched to ESMTP and MS-Mail promptly broke.
I don't recall any RFC (from the time) stating that ESMTP was REQUIRED.
It may have been a SHOULD.
The ISP chose to make the change that resulted in ESMTP.
Yes. But as per spec ESMTP was/is compatible with SMTP.
Also, I'm fairly sure that MS-Mail didn't include SMTP in any capacity.
It required an external MS-Mail SMTP gateway, which I Microsoft did
sell, for an additional cost.
Yes, it is the gateway I'm talking about ...
Which was also a pain in the neck because it was single-threaded - if
the ISP tried to send an incoming email at the same time the gateway
tried to send, the gateway hung. You could pretty much guarantee most
mornings I'd be in the server room deleting a bunch of private emails
from the outgoing queue, and repeatedly rebooting until the queues in
both directions managed to clear.
The *ONLY* acceptable reason for terminating a connection is when you
recieve the command "BYE", so when Pipex sent us the command EHLO,
MS-Mail promptly dropped the connection ...
I'll agree that what you're describing is per the (then) SMTP state
machine. We have sense seen a LOT of discussion about when it is proper
or not proper to close the SMTP connection.
The point is that when the server sends EHLO, it is *not* a *permitted*
response for the client to drop the connection.
If the MS-Mail SMTP gateway sent a 5xy error response, it could see how
it could subsequently close the connection per protocol state machine.
Pipex, and I suspect other ISPs, had to implement an extended black
list of customers who couldn't cope with ESMTP.
If the MS-Mail SMTP gateway hadn't closed the connection and instead
just returned an error for the command being unknown / unsupported,
Pipex would have quite likely tried a standard HELO immediately after
getting the response.
That was the specification for ESMTP - the client should reject EHLO,
the server tries again with HELO, and things (supposedly) proceed as
they should. Which they can't, if the client improperly kills the
connection.
Also, we're talking about the late '90s during the introduction of
ESMTP, which was a wild west time for SMTP.
Which shouldn't have been a problem. ESMTP was designed to fall back
gracefully to SMTP. But if clients don't behave correctly as per the
SMTP spec, how can the server degrade gracefully?
Cheers,
Wol
