On Tue, Mar 22, 2005 at 08:04:22PM -0500, Greg A. Woods wrote:
> [ On Tuesday, March 22, 2005 at 16:37:15 (+0000), Brian Candler wrote: ]
> > Subject: Re: [exim] Exim server behind NAT router (and HELO)
> >
> > On Mon, Mar 21, 2005 at 08:29:38PM -0500, Greg A. Woods wrote:
> > > The client host _MUST_ ensure that the <domain> parameter in a HELO (or
> > > EHLO) command is a valid principal host domain name for the client host.
> >
> > Sure; by all means it can (or even 'must') perform that test. But it is not
> > subsequently allowed to use the results of that test to influence whether or
> > not it accepts mail from that particular client.
>
> What part of "client host" don't you understand? :-)
Sorry, I misread you; you were talking about the client's responsibilities,
not the server's.
OK, so looking at RFC2821, I see in section 3.6:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
That just gives the syntax of the parameter; it must be a hostname or a
literal. The bit in parentheses says that if the client choses to send a
hostname rather than an address literal, then it must be a name which
resolves to something. (Of course, sending "
www.ietf.org" always would be
sufficient to meet that criterion)
Then in section 4.1.1.1:
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.
It doesn't yet use the word "MUST". But in 4.1.4:
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or MX
name) for its host. If this is not possible (e.g., when the client's
address is dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
domain name and supplemental information provided that will assist in
identifying the client.
Of course, even if it sends an IP address literal, it will be wrong if it's
behind a NAT firewall.
What's an "obvious name"? One which is statically configured, e.g. the
system hostname on a Unix box? Or a name obtained from reverse DNS?
Setting this aside, if I understand you rightly, you are deducing from this
that the client must behave as follows.
- if the client has been configured with a hostname (e.g. obtained from
a gethostname() system call), it cannot use it as the argument to an
EHLO/HELO command unless it has first checked in the DNS that it resolves
to some A record [3.6] and that A record belongs to this host [4.1.4]. If
it does not resolve, then it must perform a reverse DNS lookup on its own
IP address(es), and check that the forward mapping for the name found
matches one if its addresses. If that doesn't work, it must use an address
literal instead.
Well, I think if the the document had meant the client to go to that much
work, it probably would have said so explicitly (especially given that later
on it says that if the EHLO name doesn't verify, that MUST NOT cause a
message to be refused, and that this information "is for logging and
tracing only"). But that's just my opinion.
However, while we're on the topic, can you explain the phrases quoted above
"optionally followed by information that will help to identify the client
system" and "supplemental information .. that will assist in identifying the
client" ?
The grammar says:
ehlo = "EHLO" SP Domain CRLF
Domain = (sub-domain 1*("." sub-domain)) / address-literal
address-literal = "[" IPv4-address-literal /
IPv6-address-literal /
General-address-literal "]"
IPv4-address-literal = Snum 3("." Snum)
General-address-literal = Standardized-tag ":" 1*dcontent
Is there a standardized tag format for providing an IP address literal
together with supplemental information? Or is this document just internally
inconsistent?
Regards,
Brian.
