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.
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:
HELO biteme.batman.com
220 j.random.server
....
HELO eat.hot.death
220 j.random.server
....
which would produce two messages with received headers like:
Received: from biteme.batman.com (really 204.160.88.10 => freeppp.com)
by j.random.server with SMTP; Wed, 20 Dec 1995 17:17:38 -0500
Received: from eat.hot.death (really 204.160.88.10 => freeppp.com)
by j.random.server with SMTP; Wed, 20 Dec 1995 17:19:00 -0500
Keith