An email with inline jpg cannot be read by all email clients

[fpiraneo]

I'm writing a simple script to send email with inline picture in Python 3.5; because I'm a beginner I take the example on the official doc: 19.1.14.1. Examples using the Provisional API

Well, the generated email can be correctly read by Thunderbird but not on other email clients like Apple Mail and Gmail web based email.

Comparing the same message (with the same attachment) it seems that the inline attachment is encoded differently.

On the example, only the line:

1 2	with open("roasted-asparagus.jpg", 'rb') as img:     msg.get_payload()[1].add_related(img.read(), 'image', 'jpeg', cid=asparagus_cid)

...should make the magic to read the jpg and encode it properly.

Anybody with similar experiences and / or suggestions?

There is a complete Python high level library to correctly handle the building and sending of emails with attachments? The built in library (smtplib) seems too much low level... in PHP there is PHPMailer: Something similar in Python?

Thanks for answer.

Francesco

[nilamo]

Could you share the generated email? I don't know a whole lot about the python interface (I wrote something that uses inline images in C#), but if we can see the actual email that's getting sent, we can maybe figure out what's up.

Some email clients (...Outlook and Gmail, off the top of my head) will NOT show inline images from untrusted sources. So it might be working totally fine, but you have to click a link/button in order to have the images actually show up in the client.

[fpiraneo]

Well, I dig further. :-)

With python 3.5 I have this issue; with python 3.6 everything seems to works fine.

Some differences

Here is an encoded attachment generated by python 3.5:

Output:
--===============2916712276880338181==
Content-Type: image/jpg
Content-Transfer-Encoding: base64
Content-ID: <151941714105.1618.11096002067123435235@gl-18-test.fritz.box>
MIME-Version: 1.0
Content-Disposition: inline

/9j/4AAQSkZJRgABAQIAdgB2AAD/4gJkSUNDX1BST0ZJTEUAAQEAAAJUbGNtcwQwAABtbnRyUkdCIA==
WFlaIAfiAAIAFAAKAAMAFGFjc3BBUFBMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAAA==
0y1sY21zAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALZGVzYw==
AAABCAAAAD5jcHJ0AAABSAAAAEx3dHB0AAABlAAAABRjaGFkAAABqAAAACxyWFlaAAAB1AAAABRiWA==
WVoAAAHoAAAAFGdYWVoAAAH8AAAAFHJUUkMAAAIQAAAAIGdUUkMAAAIQAAAAIGJUUkMAAAIQAAAAIA==
Y2hybQAAAjAAAAAkbWx1YwAAAAAAAAABAAAADGVuVVMAAAAiAAAAHABzAFIARwBCACAASQBFAEMANg==
ADEAOQA2ADYALQAyAC4AMQAAbWx1YwAAAAAAAAABAAAADGVuVVMAAAAwAAAAHABOAG8AIABjAG8AcA==
AHkAcgBpAGcAaAB0ACwAIAB1AHMAZQAgAGYAcgBlAGUAbAB5WFlaIAAAAAAAAPbWAAEAAAAA0y1zZg==
MzIAAAAAAAEMQgAABd7///MlAAAHkwAA/ZD///uh///9ogAAA9wAAMBuWFlaIAAAAAAAAG+gAAA49Q==

...and now an encoded attachment generated by python 3.6:

Output:
--===============5725411883902186920==
Content-Type: image/jpg
Content-Transfer-Encoding: base64
Content-ID: <151941722610.87616.2407550483432365259@hercule-03.fritz.box>
MIME-Version: 1.0
Content-Disposition: inline

/9j/4AAQSkZJRgABAQIAdgB2AAD/4gJkSUNDX1BST0ZJTEUAAQEAAAJUbGNtcwQwAABtbnRyUkdC
IFhZWiAH4gACABQACgADABRhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAA
AADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtk
ZXNjAAABCAAAAD5jcHJ0AAABSAAAAEx3dHB0AAABlAAAABRjaGFkAAABqAAAACxyWFlaAAAB1AAA
ABRiWFlaAAAB6AAAABRnWFlaAAAB/AAAABRyVFJDAAACEAAAACBnVFJDAAACEAAAACBiVFJDAAAC
EAAAACBjaHJtAAACMAAAACRtbHVjAAAAAAAAAAEAAAAMZW5VUwAAACIAAAAcAHMAUgBHAEIAIABJ
AEUAQwA2ADEAOQA2ADYALQAyAC4AMQAAbWx1YwAAAAAAAAABAAAADGVuVVMAAAAwAAAAHABOAG8A
IABjAG8AcAB5AHIAaQBnAGgAdAAsACAAdQBzAGUAIABmAHIAZQBlAGwAeVhZWiAAAAAAAAD21gAB

See the difference?

Tomorrow I'll try to use the 3.6 libraries under python 3.5... maybe the server will explode... who knows! :-P

But I prefers to have some more practical ideas! Do you think there is a compatibility issue under the 3.5 libraries version?

Side notes: With python 3.5, the generated email has an higher spam score:

Output:
X-Spam-Status: No, score=3.6 required=5.0 tests=ALL_TRUSTED,
	BASE64_LENGTH_79_INF,HTML_IMAGE_ONLY_04,HTML_MESSAGE,MISSING_DATE,MISSING_MID,
	MPART_ALT_DIFF,T_REMOTE_IMAGE,URIBL_BLOCKED autolearn=no autolearn_force=no
	version=3.4.1
X-Spam-Level: ***
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on

The message generated with python 3.6 has a lower spam score:

Output:
X-Spam-Status: No, score=1.6 required=5.0 tests=ALL_TRUSTED,HTML_IMAGE_ONLY_04,
	HTML_MESSAGE,MISSING_DATE,MISSING_MID,MPART_ALT_DIFF,T_REMOTE_IMAGE,
	URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on

TIA, Francesco

[nilamo]

The == at the end of the lines from the 3.5 version are encoded new lines. A base64 encoded image shouldn't have any line breaks in it, as we can see from the working one. So if you wanted to try to make it work with both versions (really, it should, and this might be something that ends up as a bug fix for the 3.5 line), I'd start with looking at what, exactly, img.read() is giving you.

[fpiraneo]

Consider that I copies-pasted the code from the examples; consider that all the code runs correctly under python 3.6... so the solution should be simple.
Any other thought is the welcome but everything point me to think about a bug in the 3.5 libraries!