Delete attachments (but keep email)

[josaphatim]

Pullrequest

Removes specified attachment part keeping the rest of email.

Issues

• fixes Delete attachments (but keep email) #401
• relates https://avan.tech/item60587

[marclaporte]

@jasonmunro @kroky Since this is deleting data, I could use a third opinion :-)

[kroky]

Code looks good but the remove attachment itself looks a bit hacky with all that string manipulation of a mime message. Isn't it better to use a Mime lib to parse the message, remove the attachment from the message structure and then format the message again? I am afraid the current code may fail in some edge cases or ill-formatted messages and replace more than just the attachment in which case a data loss will occur.

[dumblob]

Hm, is this done transactionally? If not, could we at least do a manual two-way commit?

Deleting anything is always extremely dangerous...

[dumblob]

Got a crazy idea now. If this functionality is important for the end user (for me personally it actually is important), then why not to separate attachments from the email immediately after it was received but just before putting it into INBOX. Maybe by having a special filter or whatever. Then presenting it as one email (perhaps this is impossible and IMAP does not support anything like "merge 2 emails on the go" nor anything like "merge an email with some attachments on the go").

This way the received timestamp, IMAP ordering, etc. everything shall be "preserved". Deleting attachments at any time later would be a trivial operation not affecting the message itself.

Thoughts from IMAP experts?

[kroky]

The actual deletion consists of 3 steps done synchronously:

1. Remove attachment from the text representation of the message.
2. Create a new message on the imap server.
3. Remove the old message.

This means that data loss can't occur from the IMAP operations. If an op fails (like number 3), the worst case scenario is leaving 2 mails in the mailbox.

I think data loss could occur from improper search/replace operations on the message itself and thus I proposed to use a MIME message lib to handle the message decomposition and composition better.

Another potential problem is the creation of the message on step 2 might actually change the date of the message as IMAP stores custom creation datetime besides the Date coming from message headers. Not sure if we can modify that creation date to be the same as the original message.

[josaphatim]

The actual deletion consists of 3 steps done synchronously:

1. Remove attachment from the text representation of the message.
2. Create a new message on the imap server.
3. Remove the old message.

This means that data loss can't occur from the IMAP operations. If an op fails (like number 3), the worst case scenario is leaving 2 mails in the mailbox.

I think data loss could occur from improper search/replace operations on the message itself and thus I proposed to use a MIME message lib to handle the message decomposition and composition better.

Another potential problem is the creation of the message on step 2 might actually change the date of the message as IMAP stores custom creation datetime besides the Date coming from message headers. Not sure if we can modify that creation date to be the same as the original message.

Thanks for that @kroky. I used https://github.com/zbateson/mail-mime-parser to remove attachment.

[kroky]

Looks good to me now, thanks @josaphatim !

[kroky]

@josaphatim can you please resolve the conflict as well, so we can merge?

[josaphatim]

@josaphatim can you please resolve the conflict as well, so we can merge?

Hello @kroky. Conflicts fixed.