Survey of SMTP implementations (RFC0876)
Original Publication Date: 1983-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
Network Working Group D. Smallberg
Request for Comments: 876 ISI
Survey of SMTP Implementations
This memo is a survey of implementation status. It does not specify an
official protocol, but rather notes the status of impementation of
aspects of a protocol. It is expected that the status of the hosts
reported on will change. This information must be treated as a snapshot
of the state of these implementations.
From May to August 1983, I tested SMTP servers on the Internet to
see whether they accepted connections from the Arpanet (a Class A
network) and ISI-Net (a Class B network), whether they accepted the user
"postmaster" as a mail recipient, and whether a nonexistent user was
immediately rejected as a mail recipient.
The hosts from which the tests were conducted were ISI-VAXA on the
Arpanet (running 4.1bsd UNIX), and ISI-MOE on ISI-Net (running 4.1a).
Internet hosts were tested at various times throughout the last four
months. During the survey, I noted anomalies in a few dozen hosts' SMTP
servers; examples included a RSET command causing the server to close
the connection, a VRFY POSTMASTER evoking a reply containing an illegal
mailbox, and some cases of improper reply codes. These bugs were
reported and in most cases promptly fixed.
I would class three problems as significant because about 40 hosts
exhibit at least one of them:
1) In reply to a RSET and/or a NOOP command, some servers reply
"200", which is never a legal reply code, instead of "250".
(See sections 4.2 and 4.3 of RFC 821.)
2) If a VRFY command occurs before a MAIL command, some hosts
reply "554 Nested MAIL command". The end of section 4.1.1 of
RFC 821 states that a VRFY may occur anywhere in the session.
3) If a mail transaction is started, with a sender and receiver
specified, and a RSET is issued before the text of the message
itself is collected, some servers send a message to the sender
about being unable to deliver mail because no message was
collected. While RFC 821 doesn't rule this out, it certainly
is not consistent with the notion of resetting the transaction.
In the table in the appendix, the names and addresses of the hosts
tested were taken from the NIC host table of 17 August 1983. TACs and
echo hosts were not included in the survey.
Here are the summarized res...