Re: [Exim] caching HELO/EHLO data

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Ollie Cook
Date:  
À: exim-users
Sujet: Re: [Exim] caching HELO/EHLO data
On Wed, Mar 03, 2004 at 11:22:19AM +0000, Nigel Metheringham wrote:
> > I take this to imply that it's reasonable to expect that hosts should only
> > identify themselves with one constant string. Do others concur, or know of
> > any other place where the consistency of HELO/EHLO arguments is discussed?
>
> Nope.
>
> However think of hosts behind some form of NAT - either a NAT gateway (DSL
> users maybe, or some corporate arrangements) or a load balancing setup -
> which smells like your ebay examples.


My interpretation on this would be that:

- hosts should identify themselves with a constant string,
- but, there may be more than one host behind a particular source
address (NAT).

which makes caching HELO arguments with the source IP as the key a little
sketchy. Site's can make their own decision on what they consider acceptable to
their users, of course.

Incidentally, I think ebay are being somewhat naughty anyway since their EHLO
arguments resolve to unroutable IPs in 10/8. From RFC1918:

| If an enterprise uses the private address space, or a mix of private
| and public address spaces, then DNS clients outside of the enterprise
| should not see addresses in the private address space used by the
| enterprise, since these addresses would be ambiguous.


Additionally, RFC2821 requires an FQDN be used where available, and one
presumes that this FQDN when its A record is looked up should uniquely identify
the connecting host. Even if the document doesn't make the point explicitly, I
believe that is the sense of:

"These commands are used to identify the SMTP client to the SMTP
server... In situations in which the SMTP client system does not have a
meaningful domain name... the client SHOULD send an address literal."

None of this is specified in terms of 'MUST', so it would be hard to argue a
case for using it as part of an inbound mail policy to an affected site, but
that's up to every site administrator's preferences.

Ollie

--
Oliver Cook    Systems Administrator, Claranet UK
ollie@???               +44 20 7903 3065