Re: The issue of mime parsing

Andrew Rutherford:
> In the context of a manifest format, could we not send email
> right now with multiple MIME parts of type message/external-body
> pointing at different files on the source system?

Yes, this seems to be one way of implementing a "simplified
MIME"-approach which is very similar to what I described as a
possible solution in my last reply to Clemens Fischer. However, in
that reply I did not consider using the MIME access-type to specifiy
how to obtain the parts since I though that to be derivable from the
source email adress, but your idea seems clearly better.

Andrew Rutherford:
> And it doesn't require changing the MIME standard in any way,

I only partially agree here: it requires specifying that only a
subset of MIME is allowed for im2000 'manifests'. If generic MIME is
allowed, we would still need to parse it in the im2000 server, which
was what we started out trying to avoid.

It starts to become obvious that this 'mainifest file' actually
is a fancy-named notification file. However, to me, this discussion
has clarified two things about im2000 notifications:
  i) It is unnessecary to use generic MIME for message content.
     The issues adressed by MIME is better solved in the
     notification file (which may, or may not, be in a MIME-like
     format).
  ii) The notification file can be regarded as a part of the
     full email. It can carry all meta-data associated with
     the email and its parts and it thus enable us to handle
     all other content as ordinary binary files.

Hence, to clarify my notation: we now talk about a 'manifest section'
whithin a 'notification file' that is an integral part of an im2000
email. "To notify a receiver" then equals performing a partial email
transfer of the notification file.

Andrew Rutherford:
> My first concern is securing the email on the server to prevent
> other parties from downloading it.

These problems must be solved for all approaches that use traditional
protocols for fetching email data. They might be severe enough to
motivate a dedicated protocol. However, for the issues you mention,
HTTPS seems to be good enough.

Andrew Rutherford:
> the part that worries me is how dialup users post messages to
> their server and specify the deletion policy (after x days, after
> first retrieval, etc.

The deletion policy could be specified in the notification file. But,
as for much else in im2000, message upload requires an autenticated
and encrypted protocol. Maybe this already has been discussed in
length, but we have a huge number of protocols -- can they be
combined?
  i) "IMAP-like" : client access its email folders.
  ii) "SMTP-like" : sender uploads messages
  iii) "FTP-like" : receiver downloads message parts.
  iv) Notfication : senders email server uploads notification file
                    to receivers mail storage.

It seems to me that all these (including the more exotic features of
an IMAP-like protocol) could be combined into one autenticated
"generic network file system" protocol. In case someone out
there is interested, I would happily pick up this dicussion in a new
thread.

Andrew Rutherford:
> Mentally I'm considering a first cut to be a local-only
> authenticated SMTP submission system [3] for clients that then
> gets converted by the server into the new format

As you seem to suggest, a starting point could be to pick up an
existing implentation of an email server and:
  i) change the SMTP input code to convert ordinary MIME emails into
     the here proposed MIME-notification-file + binary parts, and
     store them so they can be accessed through HTTPS.
  ii) deliver the notification-file as an ordinary SMTP email.
     (however, probably it is a good idea to require that the
     receiving server supports encryted transfers).
  iii) into the existing 'mailque'-code add an iteration over stored
     messages, removing messages whoose deletion policy is fulfilled.

If the notification file uses a subset of MIME, and if the receiver
has a fully featured generic MIME MUA, he should be able to read the
message without any change of code on his side. However, I'm not too
happy about this implementation, since it only implements some bare
basics of im2000.

clemens fischer:
> From: and To: labels are the delivery, not the storage part of
> im2000.

You are right. However, for an easily parsed notification file, could
it be okay to combine delivery and storage? I.e., sending a message
is then equal to an autenticated upload of the notification file.
The server may still have to check that the stated sender corresponds
to the signature before acting on the message, but it would save
some protocol chat before the actual transfer.

clemens fischer:
> then again, should im2000 grow to be "the grand unified thing(tm)",
> future generations might want to send streaming data within the
> im2000 framework:  then this entire MIME-substitution business is
> voided.  delivery items may or may not point to storage items, and
> storage items could identify streams as well.

I do not understand the problem with extending the allowed subset of
MIME (or a new 'manifest' format) to specify that the content should
be obtained from a streaming source. Can you clarify on this?

Rickard:
>> [is it] possible to just keep a crypto signature of the manifest
>> file?

clemens fischer:
> people might want to fetch a single part of a message, so this
> single part needs its own checksum, delivery and storage IDs.

True, but does this single part really need its own *signature*?
What I was trying to say is that I don't think this is nessecary
if there is a hash for each part inside the notification file,
and the notification file itself is signed by the sender.

//Rickard