Gmail blocks mail with inline images if sent from hostname ending in .com

[mansonul]

• Anymail version = 2.2
• ESP (Mailgun, SendGrid, etc.) = Mailgun
• Versions of Django, python = 1.11.13, 3.6

I'm having problems sending mails to gmail accounts. If I use the attach_inline_image_file i get this from gmail:

Failed: sender@mydomain.com → receiver@gmail.com 'Email subject Server response: 552 5.7.0 This message was blocked because its content presents a potential 5.7.0 security issue. Please visit 5.7.0 https://support.google.com/mail/?p=BlockedMessage to review our 5.7.0 message content and attachment content guidelines. b12-v6si932446qtq.229 - gsmtp

I think this is happening because the image name looks like this "20180619202303.24365.655.img@domain" instead of "pic1.jpg". Is this normal? What am I doing wrong?

This is my .py file:

        message = AnymailMessage(
            subject=subject,
            body=body,
            to=recipients
        )

        cid = attach_inline_image_file(
           message,
           os.path.join(settings.ROOT_DIR, "/invitations/static/photos/2018-05-01.jpg"),
        )
        context = get_invitation_context()
        context['main_image'] = cid
        context['body'] = body
        template_html = render_to_string('invitations/invitation.html', context=context)
        message.attach_alternative(template_html, "text/html")
        message.mixed_subtype = 'related'
        message.send()

[medmunds]

Your Python code looks good. And "20180619202303.24365.655.img@domain" is a pretty typical Content-ID. (Inline attachments use a "Content ID" rather than a filename, because they're referring to content that's included elsewhere in the multipart email message.)

There might be a problem in your template. Couple of things you can check:

• Look at your generated template_html—specifically, the <img src=...>. If it looks like src="cid:20180619202303.24365.655.img@domain", that's correct. But if, say, the cid: prefix (scheme) is missing, or something has added https: or some other scheme, that would be an invalid inline image URL, which Google would correctly reject.

• If the HTML has a correct img src, then look at the generated message: print(message.message().as_string()) [edit: corrected] just before sending. You should see the plaintext and html message bodies, and then a block that looks something like:

  Content-Type: image/jpeg
  Content-Disposition: inline
  Content-ID: <20180619202303.24365.655.img@domain>
  Content-Transfer-Encoding: base64

  The exact headers and order may vary; the two important parts are (1) the Content-ID value is the same as in the HTML img src, but minus the cid: scheme and with <...> angle brackets added, and (2) the Content-Type is image/jpeg (not something that would alarm Google).

If none of that helps, please post the (relevant parts of the) template and message.as_string.

[mansonul]

I've try print(message.as_string()) but it threw me an error.
'AnymailMessage' object has no attribute 'as_string'

This is what Show original shows me:
Content-Transfer-Encoding: base64 Content-Id: <20180620063525.31107.21354.img@domain> Content-Disposition: inline; filename="20180620063525.31107.21354.img@domain" Content-Type: image/jpeg; name="20180620063525.31107.21354.img@domain" Mime-Version: 1.0

This is what I have in my html file:
<img height="auto" src="cid:{{ main_image }}" style="border:0;display:block;outline:none;text-decoration:none;width:100%;" width="400" />
and this is how it is in the mail:
<img height="auto" src="cid:20180620063525.31107.21354.img@domain" style="border:0;display:block;outline:none;text-decoration:none;width:100%;" width="400" />

The error appears only when I'm sending email from the live server, it doesn't have any problems when I send from the mailgun sandbox.

[medmunds]

OK, I've reproduced this and think I understand the issue. tl;dr: workaround until there's a proper fix is to use attach_inline_image_file(..., domain="example.jpg") (where "example.jpg" is something that doesn't end in ".com").

Here's what I think is happening…

The error appears only when I'm sending email from the live server

That's a really helpful clue. And you were on the right path with the image name being a problem:

• I'm guessing that your live server hostname (what you get when you type hostname in a shell) ends in ".com", but when you test with the sandbox you're on a hostname that ends in something else, like ".your-isp.net".

• Anymail creates an inline image's Content-ID with Python's make_msgid, which by default uses your system's hostname. So when it's working, the Content-ID looks like <12345...@ip10-1-1-10.your-isp.net>, but when Gmail blocks the message the Content-ID looks like <12345...@example.com>. Those are both valid Content-IDs, so none of this should matter, except that…

• Mailgun re-uses the Content-ID as the inline-image's filename. And Gmail blocks attachment filenames ending in ".com". (Most other ESPs allow separate filenames and Content-IDs, or just don't specify any filename for an inline image attachment.)

I'm investigating whether there's some way for Anymail to give Mailgun a separate filename for the inline image, or somehow prevent it from using the Content-ID as the filename. (Also, this may be a recent-ish Gmail or Mailgun change. I tested inline images to my Gmail account when I first wrote the Mailgun backend, but that was a few years ago.)

In the meantime, a workaround is to pass a specific domain to attach_inline_image_file:

        cid = attach_inline_image_file(
           message,
           os.path.join(settings.ROOT_DIR, "/invitations/static/photos/2018-05-01.jpg"),
           domain="example.jpg",   # <<< add this
        )

(The domain is used only to construct the Content-ID, and it doesn't really have to be a true domain. The intent is to minimize chance of Content-ID collisions between if someone forwards your message and attaches their own inline images.)

print(message.as_string()) ... error 'AnymailMessage' object has no attribute 'as_string'

Sorry about that, I meant to type print(message.message().as_string()). (But it wouldn't have actually shown the problem, as it wouldn't show the Mailgun-specific reworking of the inline image attachment.)

[medmunds]

I can't find any way to convince Mailgun's sending API to use a different filename and Content-ID for inline attachments.

I'm thinking about changing the default domain in Anymail's attach_inline* functions from Python's make_msgid default of the current hostname to something generic (and not a real domain) like "inline". That would at least make it harder to accidentally run into this behavior, while keeping spec-compliant globally-unique Content-IDs. I can't think of anything this might break.

[mansonul]

Thank you so much for looking into my problem.

My workaround was to upload the image to the server and then just point to the full url. I didn't tried your approach.

[medmunds]

This also affects Mailjet, SparkPost, and probably Mandrill.

It does not affect Amazon SES, Postmark, or SendGrid, which allow specifying Content-ID separately from attachment filename. It also wouldn't apply to Mailjet with their newer v3.1 API, but other bugs are preventing Anymail from upgrading. (And it doesn't apply to SendinBlue, which doesn't support inline images.)

[medmunds]

Fix released in Anymail v4.0.