RE: Email messages: How large is too large?

["Mason, Shane" <smason at blockade.com>]

A couple of points.  In 3) you say that you demand that message not be able
to be altered.  Can that be done?  I can only think that alteration is
detectable (signatures, et. al.)

Also, I would add that if a store and forward method is used, the message
must not be readable at the storage site.  These days, users have a minor
expectation of privacy (in fact, I would imagine that a poll of Joe Shmoe
email users would show that most of them have high expectations of privacy)
because the email process gets most mail to it's destination in one shot.
Hijacking a session is hard (for the non-dedicated), so it can't happen all
that often, and email that doesn't get sent to an intermediate hub is on and
off the net quickly.  However, if the message is stored in clear text on an
intermediary server that is universally accessable...

Security Issue.

At least most people's mail servers at, say, an ISP are behind some form of
protection from the average script kiddie, and corporate email servers are
typically behind a Firewall.  This allows the luxury of mail storage in
plain text.  However, temporary storage sites that anyone can access should
store the email in an encrypted file.  How do we get encryption into the
equation?  Is there another way?  Do we, as a group, believe that privacy is
a requirement?

ICMan

-----Original Message-----
From: Martin Djernaes [mailto:martin.djernaes at kecam-han.de]
Sent: Friday, December 17, 1999 3:59 AM
To: Vernon Schryver; ietf at ietf.org
Subject: Re: Email messages: How large is too large?


Hi Veron,


Vernon Schryver wrote:
> (I'm not replying to the list because you didn't)
Sorry - I answer back to the list....

> > I will not try to pick out all the points where we do not agree, but
> > just say than it is not always possible to create a visible metaphor for
> > a virtual function. I agree with you that we actually have or will get a
> > problem, but I can not accept that we tell the user "it was not supposed
> > to be used that way" - that does not work for me.
> 
> Of course, you must explain convincingly why it's not supposed to be
> used that way, and then offer a reasonable alternative.

Yes you are right, we should all suggest some way of solving this
problem.

I have the following "demands" to such a solution:
1. It should be possible for dial-up users to send a large message from
one user to another (relay)
2. It should be possible for a user to reject a big incomming message.
3. The message text may not be altered.
4. We should make the transmition as efficient as possible.
5. *All* users should be able to use the new service without knowing how
what it is (I already think it is a problem that we call the retrieval
service for POP3 and the transmit/send service for SMTP!)

What I could imagine is a new MIME-like mail format where all
attachments are stored in external files. When sending the messages, the
transmit protocol communicate with the relay/mail server to figure out
of the max message size (totally) it would accept. If we are below the
limit the messages it might be "legal" to attach the external messages
binary at the end of the message (including MIME-like headers). if we
are abowe the limit we transmit the attachments in a ftp like fashion or
at least as efficient as we can to a attachment-relay-server. 

Another "nice to have" feature would be the negotiate the place where to
relay the attachments. 
- Lets assume that a machine with a permanent connection to the net want
to send a large message. It would be prefered that the message is send
to the end receiver but the attachments is stored locally until the
receiver retreive/delete it (or another rule apply). 
- Lets assume that a dial-up user want to send a large message. Now it
would be prefered that the message is moved as little as possible, so
the mail client ask the mail server where to deliver the attachments.
The mail server (based on the mail of cource) try to find the closed
relay server which would accept an attachment of this size (for example
the mail server itself, or in case of missing resources another mail
server on the path to the receiver).


--- 
Regards,
  Martin Djernæs

--------------------------------------------------------------
Martin Djernæs                    martin.djernaes at kecam-han.de
Dipl.-Ing.                             
Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741
Postfach 3246                          Fax:+49 (0511) 6747 777
30032 Hannover, Germany                http://www.ke-online.de
--------------------------------------------------------------