Re: Sidewinder G2

[Michael Gale <michael () bluesuperman com>]

Oh my God -- I never said "And as you yourself note, A PROXY DOESN'T
WORK IF IT DOESN'T PRESENT A SERVER INTERFACE ON ONE SIDE.  At which
point, as far as the protocol is concerned, it's a server."

Look it you connect to a SMTP server, for example mail.bluesuperman.com
this device accepts the message. If it was a relay server or gateway it
would then forward the message onto another SMTP server and you would
see this as a SMTP "hop" or MTA in the SMTP headers.

The proxy can not and does not do this, a proxy does not accept a SMTP
message and then forward it on, it accepts incoming packets and then
forwards them on to another server after inspecting them.

If you look at the message header of a e-mail that came from a out side
server, through a SMTP application proxy to your internal SMTP server,
you would not see the address of your smtp proxy machine in the mail
headers.

What I did say was -- you can have a smtp server with out a smtp proxy
in front of it. The use would be connecting directly to the SMTP server.

You can not have a successful SMTP proxy, if there is NO server
somewhere to connect to. Which means, if you have a SMTP proxy on your
firewall. That points to a internal exchange server (bad idea), a
external SMTP server is sending the message to the exchange
server, LOOK AT THE MESSAGE HEADERS !!!! --- the message can not be sent
as in it will NOT leave the queue of the external SMTP server if the
internal exchange server is down -- because the transaction could not be
completed. 

That is what I said - now you are reading what you want to hear !!!

If the proxy was a server -- then in the above example -- the message
would NOT stay in the remote queue because your proxy would accept the
message, keep it in it's queue and the forward it to the exchange
server. But then you would see this in your message headers. 

Also if you did this -- how would you be able to tell who the message
was coming from ? Everything would look like it came from your version
of the SMTP proxy -- RBL's would not work, Reverse DNS checks, MX checks
would not work also.

Quit wording the RFC into what you want it to be. Look up SMTP servers,
SMTP relay servers and then look at the code or tcpdump and see what a
proxy does.

As long are you are reading RFC's I believe it states that every time a
message passes through a SMTP server that it most show that in the
message headers. So again -- going through a proxy does not show this in
a message header.


Michael

On Wed, 19 Nov 2003 01:05:39 -0500
Valdis.Kletnieks () vt edu wrote:

> On Tue, 18 Nov 2003 15:23:21 MST, you said:
> > A SMTP relay is NOT a SMTP application proxy -- A application level
> > proxy is NOT a server.
>
> You're being *intentionally* obtuse now.
>
> > If a application level proxy was a server, then why call it a proxy.
> > Look at your definition of a proxy you provide. It does not say that
> > IT is a server -- it goes to explain how it works using client and
> > server references and comparisions.
>
> Yes, and if you actually read the rest of the spec,you'll find that
> they consider a proxy to be logically a server and a client glued
> back to back - a server side catching inbound client requests, and
> then a client side forwarding the requests to the destination -
> similarly for an SMTP gateway - it acts as a server on the one side,
> and as a client when it talks to the "real" server on the other side.
>
> And as you yourself note, A PROXY DOESN'T WORK IF IT DOESN'T PRESENT
> A SERVER INTERFACE ON ONE SIDE.  At which point, as far as the
> protocol is concerned, it's a server.
>
> Or to quote 2821 some more:
>
>    Section 2.3 provides definitions of terms specific to this
>    document. Except when the historical terminology is necessary for
>    clarity, this document uses the current 'client' and 'server'
>    terminology to identify the sending and receiving SMTP processes,
>    respectively.
>
> OK? Got that? If you're on the receiving end of an SMTP connection,
> YOU ARE A SERVER.  If you're on the sending side, YOU ARE A CLIENT.


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html