Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Option to Easily Extract Attachments from Emails Without Packaging into .eml Files #276

Open
Ashraf-wan opened this issue Oct 12, 2024 · 2 comments

Comments

@Ashraf-wan
Copy link

Ashraf-wan commented Oct 12, 2024

I noticed that when sending emails with attachments (using tools like swaks), the attachments are bundled inside the .eml file in Base64 format.

When sending an email with swaks and using the --attach option, PaperCut captures the entire email (along with attachments) in a single .eml file, but its better to have an option where the attachments are automatically saved in the same directory (or configurable path) as separate files rather than being packaged within the .eml file.

@Jaben
Copy link
Member

Jaben commented Oct 20, 2024

but its better to have an option where the attachments are automatically saved in the same directory

Why is that better?

In v7.0 there is a new rule called "Invoke Process":

image

You can use that execute a small utility that can extract the attachments out of the EML, if you want. Something like this: https://pypi.org/project/eml-extractor/

@Kissaki
Copy link
Contributor

Kissaki commented Oct 24, 2024

File attachments have file names. Saving them in the same folder would lead to conflicts between emails.

Emails can have any number of mime bodies. Papercut is a simple email server. I think it makes perfect sense for it to save the eml file in its entirety, and not interpret one or the other type of content one way or another. If you want it to save file attachments separately, maybe you also want it to save HTML and plaintext bodies as HTML and txt files? Where does it end? Is that still a simple server?

You didn't describe a use case. For me, a single eml for every email makes perfect sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants