--no-nameless deletes valid attachments named textfile*

[martinvonwittich]

I was hoping to use ripmime to extract only the attachments of an email message while ignoring the plain-text/HTML body itself, so that I could pass the attachments to mraptor.

At first I considered to just delete all textfile* files after running ripmime, but this fails to handle a special case: a mail with the attachments foo.odt and textfile10 would be extracted like this:

host ~ # ripmime -i 885. -d x -v 
Decoding filename=textfile0
Decoding filename=textfile1
Decoding filename=foo.odt
Decoding filename=textfile10

When I now delete textfile*, I'd delete the valid attachment textfile10 too.

Then I discovered --no-nameless and I had hoped that it would correctly skip textfile0 and textfile1 (plain and HTML) while extracting textfile10, but unfortunately it falls for the same thing:

host ~ # ripmime -i 885. -d x -v --no-nameless
Decoding filename=foo.odt
Decoding filename=textfile10
Removed x/textfile10 [status = 0]
Removed x/textfile1 [status = 0]
Removed x/textfile0 [status = 0]

[flolilo]

-p : Specify prefix filename to be used on files without a filename (default text)

So I tried this out - I just created some documents (foo.odt and textfile10) and sent a mail with them to myself:

$ ripmime -i ./testmail.mbox -v -d ./ --no-nameless -p toDelete
Decoding filename=foo.odt
Decoding filename=textfile10
Removed ./toDelete1 [status = 0]
Removed ./toDelete0 [status = 0]

So as a workaround, just set -p with some really ridiculous name (e.g. plsripMIMEdeleteThis seems like a name that would never be used in a mail 😏 )

[martinvonwittich]

@flolilo nice workaround. I've took it one step further and just used a random prefix; that should make it safe enough for malware analysis:

host ~ # ripmime -i 885. -d x -v --no-nameless -p "$(openssl rand -hex 16)"
Decoding filename=foo.odt
Decoding filename=textfile10
Removed x/b0045976613564741b3875b79253dc9d1 [status = 0]
Removed x/b0045976613564741b3875b79253dc9d0 [status = 0]