On 3/22/06, John Peacock <[EMAIL PROTECTED]> wrote: > Guillaume Filion wrote: > > I don't think that your users want to use a web interface to share > > files, use the plugin for both incoming and outgoing messages. Your > > users will only have to send an email with attachment, as they > > usually do, to use the system.
Do modern e-mail users really have trouble following links embedded in e-mails? I don't think so. > That's an interesting thought. I still need to cover the situation > where the remote sender cannot send a large attachment (because of their > site policy), but that is likely to be a smaller set of users. that seems like it would be the remote site's problem. Providing a capability-based uploading space would do it -- "To send me a large file, click here and upload it using the form there" > > But then what would happen if the message is sent to multiple > > recipients, should we make different directories for each recipient? > > If not then the "delete" button would delete it for every recipient. > > Multiple recipients could get individual hardlinks to the actual file, > and the last one to click delete would actually delete the file. > However, this has the disadvantage that I have to serialize the e-mail > itself (split out all of the recipients), which is non-trivial (I've > already attempted this for a different purpose). replacing attachments with links seems to most elegant to me. The links would be a combination of a hash digest and some additional randomness. The thing that breaks is digests of the whole message, if people are sending pgp-signed attachments. The system ideally would verify pgp signatures, if provided, before breaking the message up, and would include a signed report on how the verification went to replace the signed attachments.
