Hi Frank,
I liked all these ideas very much.
But I may be of no use to you since i am newbie.
Gaurang.
--- Franck Martin <Franck(_at_)sopac(_dot_)org> wrote:
Vladis,
You won't get me I though about this one ;-)
As I said in my previous e-mail there are several
cases to handle error and
security related to such command...
First of all I feel it is important to implement
such mechanism to avoid to
increase the digital divide between countries which
have bandwidth and
countries which have not. I see so many sites which
disregard servers
because the latency is too big or the downloads are
too slow. Basically they
send the message: we don't want to talk with you
because you are inferior. I
won't give names but they exist and are not the
small companies...
Basically, I would like your cooperation in trying
to make this thing work.
If you think there is an issue try to imagine the
RESUME command exists and
how it should respond to the problem...
Enough rant, let's go back to technical issues.
The mail server needs obviously to become more
intelligent, than store,
forward and forget.
First to put the RESUME command just before DATA
ensure that most of the
sanity checks have been passed (RBL, fake domain,
ESMTP size too big,...).
So, so far nothing really has happened...
Now let see how someone could do a DOS and how the
server should avoid it.
The first principle, is not to store a mail part
indifinitively, but to
timeout it in the queue. The parameter should be
left configurable. Let's
say that the mail sender has 5mn to resume the
session or it has to start
from the beginning again. This would allow that the
queue doesn't grow out
of proportion because of errors.
The second principle, is that most servers do a
content analysis based on
the line received. The mail server, needs to know
where it is in the
session. Are we still in the headers or already in
the content? Based on
content anylysis of the mail being received the
server may send an error
back, like "Error content rejected", "Malformed
error", "Message to big".
The server trash the message and clear the session.
This would take care of
the sircam virus, like on my system where I block
attachments with .exe or
.lnk extensions. This is done easily on the fly
while receiving the e-mails.
Here the e-mail does not need to be fully received
but as soon as a
condition is met the session is closed.
The thrid issue, is that some mail system, get the
whole e-mail then pass it
to an antivirus software before re-injecting the
e-mail back into the
system. There is no possibility than to wait the
completion of the whole
session, but with the timeout above, you can't keep
a session open too
long...
Finally, there could be a separate resume queue with
a fixed size limit so
that after receiving the RESUME command the server
may answer "NOT AVAILABLE
NOW". It is then up to the sender to try to send or
try later. Later the
messages queued will expire and the RESUME queue
will be available again...
The RESUME capability is useful only for big mail in
poor network
conditions. The SIZE limit is for queue space and
processing capabilities,
it should'nt be used as a poor network configuration
parameter...
I understand that a mail server with RESUME
capability may need a bigger
queue than one without, but HD space is cheap, and
it saves huge amount of
expensive bandwidth...
So What do you think? Anybody that support the idea
and want to develop it
further?
Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
Fiji
E-mail: franck(_at_)sopac(_dot_)org <mailto:franck(_at_)sopac(_dot_)org>
Web site: http://www.sopac.org/
<http://www.sopac.org/> Support FMaps:
http://fmaps.sourceforge.net/
<http://fmaps.sourceforge.net/>
This e-mail is intended for its addresses only. Do
not forward this e-mail
without approval. The views expressed in this e-mail
may not be necessarily
the views of SOPAC.
-----Original Message-----
From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: Monday, 6 August 2001 7:45
To: Franck Martin
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Resume command for ESMTP?
On Sun, 05 Aug 2001 19:39:21 +1200, Franck Martin
<franck(_at_)sopac(_dot_)org> said:
So ESMTP could have an extension called RESUME
The protocol would be standard, except that before
DATA and after RCPT
TO, the sending server who has identified the
RESUME keyword could ask a
RESUME session...
On the other hand, SMTP is a store-and-forward
system where the files are
kept in essentially *temporary* storage. As such,
the general design
philosophy is to throw away the temporary files if a
transfer fails, so
as to free up queue space.
This in and of itself is not a problem, until you
realize that quite
possibly
more than one file may need to be saved in case the
person will *someday*
try to RESUME the transfer. Now.. a real-life case
in point.
And that's why there isn't a RESUME.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/