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

BUG: Emails with templates do not attach files correctly #37

Closed
Godlance opened this issue Mar 14, 2022 · 1 comment · Fixed by #38
Closed

BUG: Emails with templates do not attach files correctly #37

Godlance opened this issue Mar 14, 2022 · 1 comment · Fixed by #38
Labels
bug Something isn't working

Comments

@Godlance
Copy link

Godlance commented Mar 14, 2022

First of all, thank you for this life-saving library: Easy templating has been a total game-changer.

Describe the bug
When using Jinja templates, attached files are not correctly attached to the email, as the message Content-Type is set to multipart/alternative instead of multipart/mixed.

Attachments are treated by mail clients as embedded content and thus not shown or recognized as attachments.

To Reproduce
Steps to reproduce the behavior:

1.- Create a simple snippet that includes both a template and an attachment (in any form):

redmail.send(
                subject='[%s] Email data for %s' % (str(instance),str(mail_id)),
                receivers=[str(email_address)],
                html_template='jinja_template.html',
                attachments=str(os.path.join(temp_path, str(attachment_filename))),
                body_params={'json_data': json_data,},
                body_images={
                    'logo': '/tmp/ogo.png',
                },
            )

Expected behavior
The mail is shown in the email client with the attachment.

Instead, the attachment is in the mail's source code but not available to download from the client.

Email provider:

  • Email service: private postfix
  • Application to view the email: Thunderbird, Gmail Client

Environment (please complete the following information if relevant):

  • OS: Linux
  • Python version: 3.8
  • Red Mail version: 0.3.1

Additional context

It is possible to fix this issue temporalily by modifying the 'attach' method from attachment.py to always set the message as mixed:

def attach(self, msg:EmailMessage):
        if msg.get_content_type() == "text/plain":
            # We need to change the content type
            # This occurs if no body is defined or only text is defined
            # The content type is therefore changed to multipart/mixed
            # See issue #23
            msg.make_mixed()
        else:
            try:
                msg.make_mixed()
            except Exception:
                pass
        for part in self._get_parts():
            msg.attach(part)
@Godlance Godlance added the bug Something isn't working label Mar 14, 2022
@Miksus
Copy link
Owner

Miksus commented Mar 14, 2022

Thanks and thanks for reporting this! I had tedious struggles with the content-types some time ago though (related to just that piece of code you posted) and those are not really pleasant to work with.

How was your template? I tested with Windows, Python 3.8 and also Red Mail version 0.3.1 but for me the image is displaying correctly and the attachment is shown as an attachment.

My piece of code:

msg = email.send(
    sender=...,
    receivers=...,
    subject="An attachment with image and attachment",
    html="<h1>This contains an attachment and image.</h1>{{ path_image }}",
    body_images={
        "path_image": Path(__file__).parent.parent / "docs/imgs/email_emb_img.png",
    },
    attachments={"a_file.html": (Path(__file__).parent / "file.html")}
)

Looks like this in Gmail (and shown correctly on Outlook):
image

I'll test this with Linux in the upcoming days. I suspect the template should not be an issue as it should be rendered pretty much the same regardless if it comes from file or directly passed. The body_params neither sounds like an issue as I think it should be sanitized in terms of HTML by Jinja.

But I think there is things to improve anyways. I found this SO post which implies it may be best to have the top part as mixed if possible. I'll investigate this.

@Miksus Miksus linked a pull request Mar 16, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants