INTERNET-DRAFT
27th September 2000
Kumar Gaurav Khanna
Expires: 27th March 2001
Flexible proxy of mail protocols
draft-khanna-proxy-mail-protocols-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are workign documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and maybe updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document details the problem associated with the proxy of the mail
protocols (SMTP, POP3 and IMAP), and suggests a means by which their
proxy, by compliant proxy servers, can be made highly flexible,
compared to how they are proxied today.
Expires: 27th March 2001 [Page 1]
INTERNET-DRAFT draft-proxy-mail-protocols-01.txt 27th Sept. 2000
1. Introduction
There are always situations where there is a lack or restriction of
connectivity to an external network from a given network. There is
usually a computer system which is connected to the external network
and other computer systems connect to this connected computer system
in order to communicate with the external network. These connecting
systems are called CLIENTS [C], and they pass on their requests for
the external network to the computer system connected to the external
network. This connected computer system runs a software (process) which
listens for requests of the clients, for the external network, connects
to the external network on behalf of the clients, processes their
requests and sends the response back to the clients. This software is
called a PROXY SOFTWARE and the computer system running this software
is called the PROXY SERVER.
Proxy Servers proxy various protocols for the clients. HTTP is one of
the most popularly proxied protocols. There is always a need to proxy
the mail protocols as well. However, they are not proxied as much as
HTTP because of a missing link in their architecture.
2. The Problem
If you are familiar with either of the SMTP, POP3 or IMAP protocols,
then you will notice that the structure of these protocols is such
that they can work just fine when connected directly to the concerned
mail server (which, in this document refers to any server running the
SMTP, POP3 or IMAP protocols). For eg. a typical SMTP conversation
between an SMTP server [S] and SMTP client [C] is like this:
<Server waiting for connection...>
<Client connects to the server...>
S: 220 Service ready
C: HELO mydomain.com
S: 250 pleased to meet you
C: MAIL FROM:<gauravkhanna@mailandnews.com>
S: 250 sender ok
C: RCPT TO:<os_khanna@yahoo.com>
S: 250 receipient ok
C: DATA
S: 354 send data
<client sends the data, followed by the termination period>
S: 250 message accepted
C: QUIT
S: 221 transmission closed
<Client disconnects from the server>
This conversation is successful only because the client is directly
connected to the mail server. However, if an intermediary proxy server
comes into the picture, to the client, it shall seem to be the mail
server, which actually isn't true. However, the client proceeds ahead
Expires: 27th March 2001 [Page 2]
INTERNET-DRAFT draft-proxy-mail-protocols-01.txt 27th Sept. 2000
and connects to it. But the job of the proxy server is to forward the
packets it receives from the client to remote host. But the question
here is: HOW DOES THE PROXY SERVER KNOW WHICH REMOTE HOST IT HAS TO
FORWARD THE PACKETS RECEIVED FROM THE CLIENT ?
The proxy server is able to forward the HTTP packets because the HTTP
packet contains the HOST to which they have to be sent. The proxy
server gets the name of the remote host from the HTTP packet and
forwards the packet to it. But this approach isn't valid in either of
the SMTP, POP3 or IMAP protocols since neither of them support a means
to tell the proxy server the name or address of the remote host to
which the packets have to be forwarded.
Before this draft suggests a solution, lets see how currently some of
the proxy servers proxy the mail protocols, and why their approach is
rigid and inflexible in nature.
3. How mail protocols are currently proxied
Well, some of the major players in the proxy arena don't proxy the
mail protocols, mainly because of the above specified problem. But
still, there are proxy softwares which do proxy the mail protocols.
Here's what they doà
The proxy server listens on a port, say 1234, for mail packets. The
mail client is configured with the name or address and the port no.
of the proxy server. Next, the proxy server is also configured with
the name or address of the mail server to which the mail packets,
received from mail clients at port 1234, shall be forwarded. Thus,
when the client sends the packets to the proxy server, it forwards
the packets to the ONE AND ONLY PREDFINED mail server. This approach
is highly rigid, especially incase of POP3 and IMAP protocols, because
if any of the clients wishes to connect to a mail server other than
the one specified at proxy server, they can't!
To overcome this problem, some proxy software vendors have "rules"
built into their software, which can forward the requests to different
mail server, depending upon the address of the client. Well, this
approach surely solves th above mentioned problem, that is, connecting
to a mail server other than the one specified at the proxy server. But
this approach has another problem: what if someone wishes to work with
mail on two different mail servers from the same system. In this case,
the "rules" approach shall fail, because it can forward requests to
atmost one different mail server, and not more, depending upon the
address of the client. Moreover, the entire details about the mail
servers to be connected to, remains on the proxy server, which needn't
be.
4. The Solution
This draft suggests the inclusion of a new command, HOST, in the
current mail protocol architecture. It shall be used by the email
Expires: 27th March 2001 [Page 3]
INTERNET-DRAFT draft-proxy-mail-protocols-01.txt 27th Sept. 2000
client to tell the proxy server, the name or the address of the mail
server to which it should forward the mail packets. The synatx of the
HOST command is:
HOST <mail server name or address>
This command is NOT to be used when the client is connecting to the
mail server directly, and hence, has no role to play in the mail
server.
As usual, the email client is configured to use the proxy server for
mails at port 1234. So, the client goes ahead and connects to the
proxy server on that port and tells the proxy server, using the HOST
command, the mail server with which it should establish the connection.
If the proxy server is able to successfully establish a connection
with the mail server, it should send the response, which it received
from the mail server (usually the SERVICE READY response), back to the
client. Incase the connection couldn't be established, it should
give the client a error (421 incase of SMTP, -ERR incase of POP3, and
NO incase of IMAP).
Once a connection is established, the communication is carried out by
the proxy server as any other proxy commnunication. Here's an example
of the earlier described SMTP conversation, but using the HOST command
and a proxy server (C=> client, P=> proxy server, S=> mail server):
<Mail server waiting for connection...>
<Proxy server waiting for connection...>
<Client connects to the proxy server...>
C: HOST mail.mydomain.com
<Proxy server now tries to establish a connection with the mail server,
MAIL.MYDOMAIN.COM. If successful, it returns the greeting return by
the mail server. Upon error, it returns an error, as described earlier)
<Assuming connection is successfully established...>
S: 220 Service ready
P<to C>: 220 service ready
C: HELO mydomain.com
P <to S>: HELO mydomain.com
S : 250 pleased to meet you
P <to C>: 250 pleased to meet you
C: MAIL FROM:<gauravkhanna@yahoo.com>
P <to S>: MAIL FROM:<gauravkhanna@yahoo.com>
S: 250 Sender ok
P <to C>: 250 Sender ok
C: RCPT TO:<os_khanna@yahoo.com>
P <to S>: RCPT TO:<os_khanna@yahoo.com>
S: 250 Recipient ok
P <to C>: 250 Recipient ok
C: DATA
Expires: 27th March 2001 [Page 4]
INTERNET-DRAFT draft-proxy-mail-protocols-01.txt 27th Sept. 2000
P <to S>: DATA
S: 354 enter dataà
P <to C>: 354 enter dataà
<data comes here, including the termination period, from the C to P>
<P sends the same to S>
S: 250 data accepted
P <to C>: 250 data accepted
C: QUIT
P <to S>: QUIT
S: 221 Bye
P <to C>: 221 Bye
As you can see, using the HOST command, the client can tell the proxy
server with whom to establish the connectiont. This gives us more
flexibility in connection establishment and also relieves the proxy
server of maintaining the database of which mail server to connect to.
This same concept can be easily applied to the POP3 and IMAP protocols.
Also, knowledge of the HOST command is limited only to the mail clients
and the proxy server. The existing mail servers continue to work
without any problem.
I have written a mail client and proxy server supporting the proxy
SMTP protocol using this concept, and has worked just fine. If you
wish to procure its source, mail me at gauravkhanna@mailandnews.com
5. Author's Address
Kumar Gaurav Khanna,
#23, TTTI Campus,
Sector 26,
Chandigarh - 160 019
India
Phone: 91-172-773454
WWW: http://www.wintools.f2s.com/
Email: gauravkhanna@mailandnews.com
gaurav@wintools.f2s.com
Expires: 27th March 2001 [Page 5]