ietf-822
[Top] [All Lists]

A couple 821 questions

1995-12-20 14:30:51
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!

Issue 1
---------
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>     
  

Issue 2
---------
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 
this discussion.

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?

(from RFC821)
 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. 
<Prev in Thread] Current Thread [Next in Thread>