Re: The issue of mime parsing

Rickard Armiento wrote:

>  mail, my thoghts are along the lines of combining binary part-files
>  with a 'manifest'-file describing their roles. It may be the best

clemens fischer responded:

>could you describe this manifest format, please?

I recall a few years back when IETF RFC announcements had a 
multipart/alternate part after the text announcement with 
message/external-body subtypes, allowing you to download the text or 
postscript version via FTP. (My memory may be failing me here.) This 
suggests one possibility.

Going back a bit, I wrote:

>Here's an INVITE (Call setup) being sent to a phone from an anonymous
>caller. Note that although this is for a phone call, all the VoIP specific
>parts are in the message body, defined as application/sdp (Session
>Description Protocol). It could easily be message/external-body instead.

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? If you have a 100% current 
valid MIME format that contains nothing except message/external-body 
parts, is that not a manifest in all but name? And it doesn't require 
changing the MIME standard in any way, leading to a faster 
implementation time and hopefully less stuff-ups by new implementors.

That also addresses the issue of the sender specifying how they want 
to present it, wether they support breaking it up over the wire or 
not - the initial message could be a manifest of one item or many.

If I'm missing something here, shoot me down in flames quickly before 
someone else suggests a variation on the same. :-)

My first concern is securing the email on the server to prevent other 
parties from downloading it. HTTPS download [1] of a file based on 
some unique tag in the original message [2] seems like a good 
starting point, along with some auto-cleanup after download 
mechanism, but 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.)

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 (whatever that is), and appropriate 
bits get stored on that system somehow, with the server making a 
determination based on the things such as the number of recipients as 
to what the deletion policy should be.

I can see the prime advantage in dealing with UBE here is that as 
complaints come in and their stored messages get deleted off the 
server, that email can't be read by anyone further. This changes the 
equation from 1000 emails blocked from 10000 sent, to clients not 
being able to retrieve the message very quickly and so the whole 
economy of scale thing the UBE senders rely upon vanishes. Clearly 
that case has already been made on this list, so I'll try and shut up 
now.

[1] HTTPS offers the bonus of the existing certificate chain of trust 
in that world to avoid replication.

[2] Tied to Message-ID or the equivalent Call-ID in the SIP world 
seem like a good starting point.

[3] Note the "first cut" bit, I don't propose this as a long-term 
solution, more as proof-of-concept. Note that authentication would be 
required, changing this significantly from the traditional SMTP "must 
accept anything" problem.

-- 
Andrew Rutherford      sip:[email protected]      244 Pirie Street
Iagu Networks          tel:+61-8-8425-2255       Adelaide SA 5000
http://www.iagu.net/   mailto:[email protected]   Australia