output filename list only

[orange47]

Could you please add an option to only list the attachments? (so that we could use it for procmail, for eg.)
Thanks.

[inflex]

What sort of format is that usually dumped as?

[orange47]

Thank you Paul for a very quick reply :) The verbose option does the job, I think. I just need it not to write any files (can't redirect attachments to null). Thanks.

…

On Tue, 27 Mar 2018 00:33:01 -0700 Paul Daniels ***@***.***> wrote: What sort of format is that usually dumped as? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #5 (comment)

[inflex]

Ah thanks, okay, that should be fairly easy to implement.... should be.

[inflex]

An issue I've run in to already, is that many times we're still needing to write to disk to unwrap inner attachments which contain the "final" attachments; if we don't write & unwrap these files then we cannot always get to the inner attachments.

[orange47]

Oh, I see. Well thanks anyway, your program is *excellent* and very very useful. I'll try extracting to temp dir or something.

…

On Tue, 27 Mar 2018 10:43:12 +0000 (UTC) Paul Daniels ***@***.***> wrote: An issue I've run in to already, is that many times we're still needing to write to disk to unwrap inner attachments which contain the "final" attachments; if we don't write & unwrap these files then we cannot always get to the inner attachments. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #5 (comment)

[inflex]

Sadly it's a bit of a legacy limitation from the days when doing everything in RAM would have crashed the systems down pretty quick given the potentially highly parallel nature of the email filtering ( and dealing with things like massively compressed zip bombs or nested stuff ).

You probably could just setup a RAM-drive or sorts if speed is the issue?

[orange47]

yeah, I'll try that. Thanks.

…

On Tue, 27 Mar 2018 11:32:13 +0000 (UTC) Paul Daniels ***@***.***> wrote: Sadly it's a bit of a legacy limitation from the days when doing everything in RAM would have crashed the systems down pretty quick given the potentially highly parallel nature of the email filtering ( and dealing with things like massively compressed zip bombs or nested stuff ). You probably could just setup a RAM-drive or sorts if speed is the issue? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #5 (comment)