You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to provide an option to name attachments by their content id in place of, --name-by-type?
We have a process where we are using ripmime to take an maildir email and replace the embedded CID images with URL, so the email when loaded from the database does not have any of the document, or inline images as part of the data. This has been working quite well, until we run into email messages which do not name the content, which makes it difficult to link the decoded image/attachment back to the Content-ID in the header.
Right now when I use --name-by-type option, I get a sample content header block:
It will be named image001.gif and we can find it, however if option --name-by-contentid was used, it would write out _1_0C814D9C0C81499C00633EA78625828A in place.
The text was updated successfully, but these errors were encountered:
First off -- great software!
Would it be possible to provide an option to name attachments by their content id in place of, --name-by-type?
We have a process where we are using ripmime to take an maildir email and replace the embedded CID images with URL, so the email when loaded from the database does not have any of the document, or inline images as part of the data. This has been working quite well, until we run into email messages which do not name the content, which makes it difficult to link the decoded image/attachment back to the Content-ID in the header.
Right now when I use --name-by-type option, I get a sample content header block:
With actual filename that is extracted as: image-gif3
If the Content-ID has a name such as:
It will be named image001.gif and we can find it, however if option --name-by-contentid was used, it would write out _1_0C814D9C0C81499C00633EA78625828A in place.
The text was updated successfully, but these errors were encountered: