Absolutely correct, but Bill pointed out that he doesn't really care about
SMTP abuse, but in reality one really does care, but I think the point Bill
was trying to point was that it is very hard to separate out possible SMTP
malformed connections versus normal connections on a very busy site, and it
is quite possible that it may not be worth spending the money when the real
problem is somewhere else on the network..
Also, I could be completely off and have no idea what point Bill is trying
to emphasize.. :)
cheers
/m
At 05:12 PM 8/23/00 -0500, Douglas J Cameron wrote:
>Ahem..
>
>Forgive me for breaking into the topic here and possibly arriving from
>left field, but:
>
>Table 4.1 of "Internet Firewalls and Network Security" (Sijan/Hare, 1995)
>shows this:
>Port Number Description
>23 Telnet
>25 SMTP(mail)
>
>So, why would you not simply use the sepaerate port numbers for the
>seperate applications; and why would a firewall not know the difference
>between these ports?
>(Please forgive this newbie, O Great Firewall Wizards)
>
>Am I missing a huge foundation of knowledge here?
>
>On Wed, 23 Aug 2000 22:47:01 +0200 mouss <[EMAIL PROTECTED]> writes:
> > 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.]
>
>________________________________________________________________
>YOU'RE PAYING TOO MUCH FOR THE INTERNET!
>Juno now offers FREE Internet Access!
>Try it today - there's no risk! For your FREE software, visit:
>http://dl.www.juno.com/get/tagj.
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
