I was recently confronted with deciding the best way to handle the following 2
RFC821 issues and would appreciate any feedback explaining what is considered
"common" practice relating to them (and more importantly, what is the correct
behavior). You will have to bear with me on the second one as it is extremely
unlikely (and ugly) to ever happen but yet someone has brought it up as a
possibility that we should deal with. Thanks in advance!
RCPT TO: command arg does not contain the domain part. For example, a sender
SMTP issues the command "RCPT TO: <Biff>" where biff is simply a user name
After perusing the 821 and 1123, it seemed obvious that the correct action
should be for the receiver SMTP to reject the command since it violates the
required 821 syntax that requires the domain part. On the other hand, one
might argue that "hey... sendmail accepts it so you should as well". I believe
that accepting it without the domain part can lead to some serious problems
down the old mail stream. For one, if we assume that local domain delivery is
the right thing to do, the wrong people (local domain recips as opposed to some
other domain) may get mail unintentionally.
4.1.2. COMMAND SYNTAX
RCPT <SP> TO:<forward-path> <CRLF>
<forward-path> ::= <path>
<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
<mailbox> ::= <local-part> "@" <domain>
An SMTP session is established, a single message is received successfully by
the receiver SMTP and the sender SMTP decides to issue a 2nd HELO command using
a different domain name than sent with the arg of the first HELO command prior
to sending a 2nd message over this same session. Please assume that no
validation is being performed on the HELO command arg by the receiver SMTP for
It seems that allowing a 2nd HELO is not only unnecessary but capable of
causing incedious mail tracking problems since the Received header is
constructed with it's contents. Is there any valid use to allow a second HELO
command within the same session?
4.1.1. COMMAND SEMANTICS
The first command in a session must be the HELO command.
The HELO command may be used later in a session as well. If
the HELO command argument is not acceptable a 501 failure
reply must be returned and the receiver-SMTP must stay in
the same state.