There is nothing that a firewall can use to distinguish a "normal"client
from a guy who telnet to the
port, for the simple reason that both are exactly the same thing.
an smtp connection consists of a client connectiing to port 25 of a host
sending commands and
reading responses. This client may be anything that is capable of handling
a TCP connection.
The telnet program may be used for this.
so a firewall that rejects an SMTP connection just because it thinks it is
coming from a "user doing
telnet" is not only stupid, but it is not serving SMTP. relying on headers
is not only useless, it is a
loss of developpers energy, of the host CPU and yet another source of bugs.
The problem of forged SMTP connections is the same as that of forged
letters. the only way to guard against
is to add a verification process which makes it harder to communicate by
email. you can use encryption to make
sure who sent what, but only if you know who can send you mail. if you
accept to receive email from anybody,
then that's it, you choosed to get served, accept the risks....
mouss
At 10:43 23/08/00 -0700, [EMAIL PROTECTED] wrote:
>The characteristics of a Telnet connection are significantly different
>from a standard SMTP connection and some firewall proxies can recognize
>and drop Telnet connections but what's the point? It's trivial to create
>an interactive SMTP emulation that would bypass this check. The port is
>designed to for TCP connections that passes ASCII text characters. What
>would you be accomplishing by preventing/dropping Telnet connections?
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
