Skip to content

Add email related content support (RFC2387). #1329

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add email related content support (RFC2387). #1329

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion apprise/plugins/email/base.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -927,7 +927,7 @@ def prepare_emails(subject, body, from_addr, to,
base = MIMEText(body, 'plain', 'utf-8')

if attach:
mixed = MIMEMultipart("mixed")
mixed = MIMEMultipart("related")
Copy link
Owner

@caronc caronc May 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great to support having the attachments show inline, but this isn't ideal for say a non-graphical attachment. Say a video, pdf, etc to which "mixed" is still a better option.

I think there are 2 levels needed here... one, only switch to inline if an option on the mailto:// is provided ... perhaps a ?inline=yes option. and ONLY if that is set, an additional check needs to be made right here in the code you changed. One that just looks at attach.mimetype... something like:

if attach.mimetype.startswith('image/'):
   mixed = MIMEMultipart("mixed")

Here is an example of where this kind of check exists elsewhere.

Forcing everything to be inline though (per RFC2387) is not ideal. Thoughts?

Copy link
Author

@MarcosLenharo MarcosLenharo May 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with your suggestion of creating a new switch.

One thing that I'm not sure is whether the new switch should follow item 4 of RFC2387 and change the Content-Disposition tag from "attachment" to "inline" to help non-RFC2387 compliant clients to handle it.

Regarding your suggestion on checking the attach.mimetype: The "mixed" type is at the top of email body, not on the attachment level, so it would be necessary to list all attachments and check if at least one of them is a "image/" and then change the multipart type.

What do you think about these two points?

mixed.attach(base)
# Now store our attachments
for no, attachment in enumerate(attach, start=1):
Expand Down Expand Up @@ -959,6 +959,10 @@ def prepare_emails(subject, body, from_addr, to,
Header(filename, 'utf-8')),
)
mixed.attach(app)
app.add_header(
'Content-ID',
'<{}>'.format(Header(filename, 'utf-8')),
)
base = mixed

if pgp:
Expand Down