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 [EMAIL PROTECTED] 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
