11

When sending emails using the Gmail API, it places hard line breaks in the body at around 78 characters per line. A similar question about this can be found here.

How can I make this stop? I simply want to send plaintext emails through the API without line breaks. The current formatting looks terrible, especially on mobile clients (tested on Gmail and iOS Mail apps).

I've tried the following headers:

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: quoted-printable

Am I missing anything?

EDIT: As per Mr.Rebot's suggestion, I've also tried this with no luck:

Content-Type: mixed/alternative

EDIT 2: Here's the exact format of the message I'm sending (attempted with and without the quoted-printable header:

From: Example Account <example1@example.com>
To: <example2@example.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: This is a test!
Date: Tue, 18 Oct 2016 10:46:57 -GMT-07:00

Here is a long test message that will probably cause some words to wrap in strange places.

I take this full message and Base64-encode it, then POST it to /gmail/v1/users/{my_account}/drafts/send?fields=id with the following JSON body:

{
    "id": MSG_ID,
    "message": {
        "raw": BASE64_DATA
    }
}
Community
  • 1
  • 1
Hundley
  • 3,167
  • 3
  • 23
  • 45
  • Have you tried setting it to `mixed/alternative`? See the related [SO question](http://stackoverflow.com/a/34165728/5995040) for code implementation. Hope this helps. – Mr.Rebot Oct 18 '16 at 09:34
  • @Mr.Rebot I gave it a try, but it actually made the whole message become a file attachment instead of displaying the body. – Hundley Oct 18 '16 at 17:39
  • Hi Hundley! Not sure if you've gotten this working yet on not, but a valid option is to use 7bit encoding rather than trying to send using quoted-printable. If you don't need the QP encoding, 7bit will do exactly what you want. When sending with Gmail it will detect that your message is not properly QP encoded and likely mess with your line breaks for you. Alternatively, please take a look at the format=flowed/format=fixed options for your content-type (https://www.ietf.org/rfc/rfc2646.txt). Hope that's useful! – Grant Watters Nov 01 '16 at 22:34

3 Answers3

4

Are you running the content through a quoted printable encoder and sending the encoded content value along with the header or expecting the API to encode it for you?

Per wikipedia it seems like if you add soft line breaks with = less than 76 characters apart as the last character on arbitrary lines, they should get decoded out of the result restoring your original text.

UPDATE

Try sending with this content whose message has been quoted-printable encoded (base64 it):

From: Example Account <example1@example.com>
To: <example2@example.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: This is a test!
Date: Tue, 18 Oct 2016 10:46:57 -GMT-07:00

Here is a long test message that will probably cause some words to wrap in =
strange places.
cchamberlain
  • 17,444
  • 7
  • 59
  • 72
  • I've updated my question with the exact format of the message I'm sending. What I fail to understand is why Gmail is messing with line breaks at all... when I send an email through the web client it doesn't enforce line breaks, so why would the API? – Hundley Oct 19 '16 at 06:09
  • @hundley when you send it via the email client it likely still 'soft breaks' the lines per the specification that all email clients abide by, you just never see this step because soft breaks are removed on the receiving end when the content is `quoted-printable` decoded. If you add soft breaks to the content you are sending, it should get decoded in the receiving email client with no line breaks. If you do not and lines exceed 76 characters, google is going to add them for you. Your update does not appear to contain soft breaks. – cchamberlain Oct 19 '16 at 06:41
  • Here is a link to the IETF specification with the reasoning for why the maximum length of 76 characters - [RFC2822](https://tools.ietf.org/html/rfc2822#section-2.1.1). To be clear, google is just implementing the specification set forth by the governing committee, they did not create the rules, they just abide by them (most the time). ;) – cchamberlain Oct 19 '16 at 06:54
1

I'm assuming you have a function similar to this:

1. def create_message(sender, to, cc, subject, message_body):
2.     message = MIMEText(message_body, 'html')
3.     message['to'] = to
4.     message['from'] = sender
5.     message['subject'] = subject
6.     message['cc'] = cc
7.     return {'raw': base64.urlsafe_b64encode(message.as_string())}

The one trick that finally worked for me, after all the attempts to modify the header values and payload dict (which is a member of the message object), was to set (line 2):

  • message = MIMEText(message_body, 'html') <-- add the 'html' as the second parameter of the MIMEText object constructor

The default code supplied by Google for their gmail API only tells you how to send plain text emails, but they hide how they're doing that. ala... message = MIMEText(message_body)

I had to look up the python class email.mime.text.MIMEText object. That's where you'll see this definition of the constructor for the MIMEText object:

  • class email.mime.text.MIMEText(_text[, _subtype[, _charset]]) We want to explicitly pass it a value to the _subtype. In this case, we want to pass: 'html' as the _subtype.

Now, you won't have anymore unexpected word wrapping applied to your messages by Google, or the Python mime.text.MIMEText object

Andrew
  • 1,423
  • 1
  • 17
  • 26
1

This exact issue made me crazy for a good couple of hours, and no solution I could find made any difference.

So if anyone else ends up frustrated here, I'd thought I'd just post my "solution".

Turn your text (what's going to be the body of the email) into simple HTML. I wrapped every paragraph in a simple <p>, and added line-breaks (<br>) where needed (e.g. my signature).

Then, per Andrew's answer, I attached the message body as MIMEText(message_text, _subtype="html"). The plain-text is still not correct AFAIK, but it works and I don't think there's a single actively used email-client out there that doesn't render HTML anymore.

John
  • 11
  • 1