I've had a request for a setting where attachments are automaticallyI also think there needs to be a way to prevent that for important attachments.
I think that goes along with the request to provide a way to copy an attachment into the Files section. I'd suggest that "copy" mean creating a second link to the data, not a literal copy of the data (so that the copy doesn't cost extra storage). I think that means having something like inode reference counts in Unix filesystems.
In this case the presence of the additional link(s) could prevent the attachment from disappearing from the message (no sense breaking that if the group elected to keep the file content).
Maybe, like my TiVo, there needs to be a limited duration "Undelete" list, where the (about to be permanently) deleted attachments spend some time in limbo, affording the moderator a chance to review them and recover the desired ones. I guess that's also the equivalent of Windows' Recycle bin. Or maybe that's just a bit much.
Also, somewhat related, is the following: If you compose an HTMLIf the HTML images are sourced as "cid:" references it might not be too hard to recognize that they are all the same content, discard all but one, and fixup the other references ("how hard could it be?", he says glibly). That's assuming the various email systems aren't in the habit of recoding the images when they quote them.
I've seen a recent trend towards sourcing them as "data:". Maybe it is feasible to convert them all to a common "cid:" reference to a single MIME part? I don't know if there are semantic or syntactic reasons that might be a bad idea.
Of course, if the images are external ("http:" sourced) then there isn't a storage problem at all, in either the email message or the stored attachments.