[Top] [All Lists]

Re: A couple 821 questions

1995-12-20 15:52:28

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 
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 
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 
the right thing to do, the wrong people (local domain recips as opposed to 
other domain) may get mail unintentionally. 

RCPT TO:<somebody> is inherently ambiguous, which is one reason that it's
not allowed by the standard.  But the standard does not specify how an SMTP
server should react to nonstandard recipient addresses in RCPT commands,
so in principle the server can handle it any way it wants to.

My suggestion: if you do support RCPT TO:<somebody> (with no @domain), the 
interpretation should be to send it to the local user with username 
"somebody", rather than to forward it to some unnamed host.  Of course, for a 
mail gateway, there might not be any "local users" to speak of, so RCPT 
TO:<somebody> would usually result in an error.   But if you support RCPT 
TO:<somebody> at all, make sure that, RCPT TO:<postmaster> goes to the local 
system maintainer of the SMTP server.  For a gateway, it might even be 
reasonable to have Postmaster as the *only* address for which RCPT 
TO:<somebody> works.

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?

If for no other reason than backward compatibility, you must accept multiple 
HELOs, even if the domains differ.  This doesn't really introduce any new 
tracking problems since SMTP isn't authenticated anyway...a spoofer can always 
close the TCP connection and open another one.  As for tracking, you should 
include both the domain from HELO and the source IP address in the Received 
header.  (You can also do the inverse lookup on that address if you wish.)  
The domain that came from the HELO command should go in the "from" clause, 
while the IP address should go in a following comment.  Example:

220 j.random.server
220 j.random.server

which would produce two messages with received headers like:

Received: from (really =>
 by j.random.server with SMTP; Wed, 20 Dec 1995 17:17:38 -0500

Received: from (really =>
 by j.random.server with SMTP; Wed, 20 Dec 1995 17:19:00 -0500


<Prev in Thread] Current Thread [Next in Thread>