[ On Tuesday, March 22, 2005 at 15:58:11 (+0100), Jakob Hirsch wrote: ]
> Subject: Re: [exim] Exim server behind NAT router (and HELO)
>
> Sure, but what is a server about to do when the clients lies in
> HELO/EHLO (wether by intention or not)?
That depends entirely on the server.
Those who blindly follow rules without thinking them through will accept
the lies.
Those of us who do not allow 20-year old documents that were known to
contain political compromises even before they were published to dictate
policy to us will be a little more choosy about which clients we allow
to lie and which we refuse on that basis alone.
> Setting up a server in a way to block mail from such a client
> "because they do not behave rfc-compliant" is simply hypocritical.
This isn't really a question about RFC compliance -- this is an issue of
trust and competence (and DoS protection)
Do you trust someone who introduces themselves to you as some important
person when they clearly are not that person? Would you trust someone
claiming to be you or someone you represent? I certainly don't do
either -- unless maybe I'm at a costume party amongst friends.
Should your mailer trust a connecting client claiming to be from
yahoo.com if it clearly is not? Should your mailer accept transactions
from some remote host claiming to be your own mailer? For me the answer
to those questions has always been an emphatic NO!
> You
> cannot enforce a rule by breaking it yourself.
Ah, the fallacy of misunderstanding the difference betweeen protocol and
policy. You need to learn the difference before you can truly be
successfull at reading and interpreting RFCs. :-)
> If you that as your local
> policy, then be it so, it's your own business.
Exactly. No RFC is allowed to dictate (security) policy to any site.
The second paragraph of RFC 1123 section 5.2.5 tries to do exactly that.
> But don't accuse anybody of "rfc-violation" then.
You're assumptions are incorrect.
> > VERY simple little requirement and one that is almost impossible for any
> > valid SMTP client host on the modern Internet to not be able to comply
> > with.
>
> That's simply not true. Many clients sit behind NATed gateways today,
What part of "NATs must be transparent" don't you understand?
It really is VERY TRIVIAL and VERY SIMPLE, downright child's play I'm
sure, to configure any proper SMTP "client" to greet other servers it
conntects to with what will be its public hostname as perceived by those
remote servers.
(and if that is not possible then some other fundamental tennant of good
Internet practices is being violated, such as attempting to use a
dynamic address for a mail server)
> You don't want the gateway to translate that...
(Actually maybe you do -- but there shouldn't be any need for such
complexity.)
Personally I find it completely silly to think that running a mail
server behind a NAT is of any value whatsoever.....
(and running servers behind a NAT that's using a dynamic IP is just
plain crazy and those trying it deserve all possible problems to plague
them until they learn to mend their ways)
> Greg, what is your point? HELO/EHLO information is really the least
> useful information in the whole SMTP transaction.
Actually the greeting command is the most critical first step in the
transaction.
You cannot protect your server from several types of potentially
damaging DoS attacks if you do not at least ensure that it refuses
connections from clients claiming to be itself (or from other names that
it is responsible for handling). That's why there is a greeting command
in the first place. The fact that you can also detect obvious lies and
get a measure of trust from the greeting command is also something that
was clearly apparent even 20 years ago when the rationale for 1123§5.2.5
was first written, though the importance of that capability wouldn't be
fully recognized by most folks for at least a decade afterwards.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
