Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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
                Have you tried setting it to mixed/alternative? See the related SO question for code implementation. Hope this helps.
– Mr.Rebot
                Oct 18, 2016 at 9: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, 2016 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 (ietf.org/rfc/rfc2646.txt). Hope that's useful!
– Grant Watters
                Nov 1, 2016 at 22:34
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.
                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, 2016 at 6: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, 2016 at 6:41
                Here is a link to the IETF specification with the reasoning for why the maximum length of 76 characters - RFC2822. 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, 2016 at 6:54
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.
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.
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.