I don't see this topic discussed in the list archive.
When sending a mail message from some ESMTP clients to some ESMTP servers,
and the network or the server is highly congested, it is possible that the
message will be deferred as a result of RFC 1651/1869 inherent bug that
leads to "503 Duplicate HELO/EHLO" from an ESMTP server.
The following ia an example of an ESMTP session. C stands for an ESMTP
client, S for an ESMTP server implementing that buggy behavior:
S: 220 [greeting]
C: EHLO client.example.org [tries to negotiate ESMTP]
S: [not responding in expected time]
C: HELO client.example.org [tries to estabilish plain SMTP]
S: 250-server.example.org [responds to the EHLO]
S: 250-[ESMTP features]
S: 250 8BITMIME
S: 503 Duplicate HELO/EHLO [responds to the HELO]
C: QUIT
Exchange Server SMTP Service version 5.5 is an example of client working
that way. It tries to negotiate ESMTP features where available (e.g. to not
attempt to send message when its size exceeds RFC 1427's SIZE), or sends
message via plain SMTP otherwise.
The bug in RFC 1869 may be explained as follows:
1. RFC 1869 extends RFC 821 (look at p. 4.1).
2. RFC 821 p. 4.1.1 (page 27) allows using HELO multiple times during
a session. RFC 821 p. 4.1.1 (page 19) defines conditions under which
HELO returns positive or negative response.
3. RFC 1869 p. 4.2 says an EHLO may be issued at any time that a HELO
would be appropriate.
4. RFC 1869 p. 4.2 then denies itself saying that after a successful
server response to first EHLO, all subsequent HELO/EHLOs must return
error 503.
Here are my own mini-survey on (E)SMTP servers and their buggy-RFC-1869
behavior:
+-----------------------------------------------+-----------------+
| (E)SMTP server software name | RFC 1869 bug? |
+-----------------------------------------------+-----------------+
| qmail 1.03 | no |
| ZMailer 2.99.52-patch1 | no |
| Exim 2.12 | no |
| MS SMTP Mail 5.5.* | no |
| MailShield SMTPCisco SMTP Gateway | no |
| America Online mail version 71.10 | no |
| HotMail ESMTP server | no |
| Lotus Domino 5.0.2a ESMTP Service | no |
+-----------------------------------------------+-----------------+
| sendmail 8.8.8, 8.9.1, 8.9.3 | YES |
| Postfix up to snapshot 20000309 | YES |
| Mercury 1.44 | YES |
| Rayan S. Zachariassen ESMTP Server (mail.net) | YES |
+-----------------------------------------------+-----------------+
| CheckPoint FireWall-1 Secure SMTP Server | plain SMTP only |
| MudMail 1.71 | plain SMTP only |
| GroupWise Internet Agent 5.5.3.1 | plain SMTP only |
+-----------------------------------------------+-----------------+
"no" in the second column means that the server allows multiple HELOs/EHLOs
per session. "YES" means the server is affected by the issue. "Plain SMTP
only" means EHLO wasn't accepted by the server.
As you know, qmail accepts mail from client that doesn't issue HELO/EHLO at
all. Now it is clear that qmail also accepts mail when others fail.
Regards,
Andrzej Kukula
