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
}
}
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'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
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.
Related
Executive summary: I can construct a multipart message which contains HTML in two separate parts, and it displays correctly in multiple MUAs. However, outlook.com insists on putting any additional HTML after the first HTML part in a downloadable attachment, instead of displaying it. It also does this for plaintext parts.
In detail: I need to add a signature to an email message, where the structure of the original message is, in general, unknown. I do this by wrapping the original message in a multipart/mixed, and then adding a new multipart/alternative which contains text and html versions of the required signature.
If the original message was itself a multipart/alternative, then the new message now looks like:
multipart/mixed
multipart/alternative [the original message]
text/plain
text/html
multipart/alternative [the appended signature]
text/plain [plaintext signature]
text/html [html signature]
This displays well in various clients (Thunderbird, and webmail from gmail/Yahoo/AOL/gmx), showing the original message with the appended signature. However, it doesn't work for MS clients (I've only tried outlook.com). The two alternative signatures are presented to the user as attachments, and not inline, so the user only sees download boxes.
To get around this, I've historically done this for Microsoft:
multipart/mixed
multipart/alternative [the original message]
text/plain
text/html
text/html [html-only signature]
This worked for several years for Microsoft, but has now stopped working - the signature is again shown as an attachment.
I've spent some hours experimenting with this, and can't find any way to get outlook.com to show two different HMTL (or even plain) text parts in the same message. The second one always appears as an attachment. Some of the things I've tried are:
Replace the second multipart-alternative above with another multipart/mixed, which encloses the multipart-alternative signature
Trying to force Content-Disposition: inline for the signature: this never works, and MS appears to ignore Content-Disposition
Replace the outer multipart/mixed with multipart-related, with type=multipart/alternative
Any ideas on how I can get MS clients to actually show the signature, short of parsing the internals of the original message and re-writing it?
I'm using Keycloak 15.0.2. When sending an account verification email, the email that gets sent uses Content-Transfer-Encoding: 7bit for the text portion of the email.
This causes the verification link to be on one line, and violates RFC 2822 by having a line that's very long, causing my emails to be bounced.
The HTML portion of the email is properly encoded with Content-Transfer-Encoding: quoted-printable.
I've been trying to look at the source of Keycloak, but my knowledge of java is too poor to really figure it out. I'm sure somewhere the MIME message gets parsed at which point it decides on a header for each part. But I can't find where.
I have seen messages where the text portion did have the correct encoding. So I assume there's a certain condition somewhere that will force the encoding. But I can't find it.
How can I force Keycloak (or Freemarker, or javax MimeBodyPart) to use quoted-printable?
Example of a MIME output:
Content-Type: multipart/alternative; boundary="----=_Part_2_1488711957.1660016366185"
Date: Tue, 9 Aug 2022 03:39:26 +0000 (GMT)
From: Mails#covle.com
MIME-Version: 1.0
Message-ID: <126146379.3.1660016366188#b02efe4baa19>
Received: from b02efe4baa19 by mailhog.example (MailHog)
id duuNy3ONelpvr8ukUqz7WBJnrtPd0oSw43G2W9w8Ix4=#mailhog.example; Tue, 09 Aug 2022 03:39:26 +0000
Reply-To: Mails#example.com
Return-Path: <Mails#examplecom>
Subject: Verify email
To: asdasd#example.com
------=_Part_2_1488711957.1660016366185
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Someone has created a Bluppie account with this email address. If this was you, click the link below to verify your email address
http://localhost:8080/auth/realms/bluppie/login-actions/action-token?key=eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIzODYxY2JmMy0wMWYzLTRhMmQtOTg1NC02MmEyYWMyYzhjNzUifQ.eyJleHAiOjE2NjAwMTY2NjYsImlhdCI6MTY2MDAxNjM2NiwianRpIjoiZDVlYjlhODMtMDE0NS00YTBhLTk2M2YtYjBkMjI0ZTA0ZWVkIiwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL2F1dGgvcmVhbG1zL2JsdXBwaWUiLCJhdWQiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvYmx1cHBpZSIsInN1YiI6IjIxOGQ1NzkzLTA0NmYtNDQ4NS04ZmIxLTQ0M2E5NjEyM2FmZiIsInR5cCI6InZlcmlmeS1lbWFpbCIsImF6cCI6ImFjY291bnQiLCJub25jZSI6ImQ1ZWI5YTgzLTAxNDUtNGEwYS05NjNmLWIwZDIyNGUwNGVlZCIsImVtbCI6ImFzZGFzZEBjb3ZsZS5jb20iLCJhc2lkIjoiNmM3ZTk5NGItZTA0ZS00ZTlkLWFkNTQtZjE1MGM4NjcwYzdmLlFfQ244SlY0WFlBLmQ1MzI3MTMwLWIzY2EtNDY4Ny1iZDZkLWViZWFiODAwZTdkMyIsImFzaWQiOiI2YzdlOTk0Yi1lMDRlLTRlOWQtYWQ1NC1mMTUwYzg2NzBjN2YuUV9DbjhKVjRYWUEuZDUzMjcxMzAtYjNjYS00Njg3LWJkNmQtZWJlYWI4MDBlN2QzIn0.yrTUf2tl521Q00IUL-2dWTnugUt_ZeATa3W3IrgoRGM&client_id=account&tab_id=Q_Cn8JV4XYA
[NOTE: The line above is the RFC violation.]
This link will expire within 5 minutes.
If you didn't create this account, just ignore this message.
------=_Part_2_1488711957.1660016366185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<body>
<p>Someone has created a Bluppie account with this email address. If this w=
as you, click the link below to verify your email address</p><p><a href=3D"=
http://localhost:8080/auth/realms/bluppie/login-actions/action-token?key=3D=
eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIzODYxY2JmMy0wMWYzLTRhMmQ=
tOTg1NC02MmEyYWMyYzhjNzUifQ.eyJleHAiOjE2NjAwMTY2NjYsImlhdCI6MTY2MDAxNjM2Niw=
ianRpIjoiZDVlYjlhODMtMDE0NS00YTBhLTk2M2YtYjBkMjI0ZTA0ZWVkIiwiaXNzIjoiaHR0cD=
ovL2xvY2FsaG9zdDo4MDgwL2F1dGgvcmVhbG1zL2JsdXBwaWUiLCJhdWQiOiJodHRwOi8vbG9jY=
Wxob3N0OjgwODAvYXV0aC9yZWFsbXMvYmx1cHBpZSIsInN1YiI6IjIxOGQ1NzkzLTA0NmYtNDQ4=
NS04ZmIxLTQ0M2E5NjEyM2FmZiIsInR5cCI6InZlcmlmeS1lbWFpbCIsImF6cCI6ImFjY291bnQ=
iLCJub25jZSI6ImQ1ZWI5YTgzLTAxNDUtNGEwYS05NjNmLWIwZDIyNGUwNGVlZCIsImVtbCI6Im=
FzZGFzZEBjb3ZsZS5jb20iLCJhc2lkIjoiNmM3ZTk5NGItZTA0ZS00ZTlkLWFkNTQtZjE1MGM4N=
jcwYzdmLlFfQ244SlY0WFlBLmQ1MzI3MTMwLWIzY2EtNDY4Ny1iZDZkLWViZWFiODAwZTdkMyIs=
ImFzaWQiOiI2YzdlOTk0Yi1lMDRlLTRlOWQtYWQ1NC1mMTUwYzg2NzBjN2YuUV9DbjhKVjRYWUE=
uZDUzMjcxMzAtYjNjYS00Njg3LWJkNmQtZWJlYWI4MDBlN2QzIn0.yrTUf2tl521Q00IUL-2dWT=
nugUt_ZeATa3W3IrgoRGM&client_id=3Daccount&tab_id=3DQ_Cn8JV4XYA" rel=3D"nofo=
llow">Link to e-mail address verification</a></p><p>This link will expire w=
ithin 5 minutes.</p><p>If you didn't create this account, just ignore t=
his message.</p>
</body>
</html>
------=_Part_2_1488711957.1660016366185--
tl;dr: Add any non US-ASCII character to your templates and it will be encoded as quoted-printable.
On some cached page I found some old documentation which seem to explain the logic:
getEncoding
public static String getEncoding(DataSource ds)
Get the Content-Transfer-Encoding that should be applied to the input stream of this DataSource, to make it mail-safe.
The algorithm used here is:
If the DataSource implements EncodingAware, ask it what encoding to use. If it returns non-null, return that value.
If the primary type of this datasource is "text" and if all the bytes in its input stream are US-ASCII, then the encoding is "7bit". If more than half of the bytes are non-US-ASCII, then the encoding is "base64". If less than half of the bytes are non-US-ASCII, then the encoding is "quoted-printable".
If the primary type of this datasource is not "text", then if all the bytes of its input stream are US-ASCII, the encoding is "7bit". If there is even one non-US-ASCII character, the encoding is "base64".
Parameters:
ds - the DataSource
Returns:
the encoding. This is either "7bit", "quoted-printable" or "base64"
I am using mimedefang filtering tool. In the configuration, I strip out all the attachments and forward it to another address. For particular sender, I can see milter changes the header Content-Type from application/pdf and multipart-mixed. In the received email on outlook, when I open the pdf using text editor (it contains content like ("This is a multi-part message in MIME format..." followed by some random numbers "------------=_1525668389-64274-8--").
Can anyone guess why this might be happening?
Multi-part messages (like those with attachments) have their parts divided by a boundary. This boundary is between 1 and 70 characters and must not appear anywhere in the anywhere within the encapsulated parts of the message (between boundaries).
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p
This is a message with multiple parts in MIME format.
--gc0p4Jq0M2Yt08jU534c0p
Content-Type: text/html; charset=UTF-8
<html><head></head><body>This is the HTML body of the message.</body></html>
--gc0p4Jq0M2Yt08jU534c0p
Content-Type: text/plain
This is the body of the message.
--gc0p4Jq0M2Yt08jU534c0p
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--gc0p4Jq0M2Yt08jU534c0p--
I suspect that somewhere between mimedefang and your milter configuration, the boundaries are getting mangled or included into the attachment can causing them to be corrupted.
I have a requirement to add a signature to emails passing through a specialised proxy server. There doesn't seem to be a very good way to do this, and my initial thoughts are to:
If the mail is non-MIME, or is text/plain, just add text to the bottom of the body,
with a preceding "-- " line (an old convention for adding signatures
to text/plain messages; see RFC3676, 4.3)
If the mail is multipart/mixed, find the last boundary, and insert
a new `multipart/alternative' entity above it, containing plain and
HTML versions of the sig. This has the disadvantage that the sig may
appear below attachments, though.
If the mail is not multipart/mixed, make it multipart-mixed, and
demote the existing entities into the mixed section; now add the
multipart/alternative signature as the last part of the new
multipart/mixed. Same disadvantage as (2).
Seems pretty long-winded. Any ideas on better ways to do this? Thanks.
I coded this as above, and it's fine on Yahoo, gmail, AOL, GMX, and Thunderbird, with the MIME validated here and here.
The problem was that I forgot, again, about Microsoft's complete inability to read an RFC. If a multipart/mixed section contains two multipart/alternative sections, where each one contains a text/plain and a text/html alternative, then Outlook/hotmail actually displays both alternatives in the second multipart/alternative. So, it displays both the plain signature, and the HTML version.
The fix is straightforward - instead of adding a second multipart/alternative for the signatures, I instead add a single text/html section, containing only the HTML signature. This displays correctly on all the MUAs above, including the brain-dead ones. Not exactly ideal, but I could enable the fix only for Microsoft recipients, and let them sort things out if they have persuaded their MUA to display only plain text.
if only interesting in text/html and not in text/plain part, a bit simpler implementation will be to trasform the text/html into multipart/mixed with your html signature.
before
multipart/alternative
text/plain
text/html
after
multipart/alternative
text/plain
multipart/mixed
text/html
text/html <== your signature
Requirement: To send VB file of records length 100 as attachment using TCPSMTP utility with proper message in body without using IEBGENER utility.
I am trying to send email attachment file VB dataset as attachment. Its working either message in attachment or attachment file in body. But both simultaneously not working.
My JCL is:
//IRTCPN15 EXEC PROC=TCPSMTP
//SMTPIN DD DSN=EMAIL.CODE,
// DISP=SHR
// DD DSN=FILE.TOBE.SENTAS.ATTACH.MENT,DISP=SHR
Here, I have used both datasets EMAIL.CODE and FILE.TOBE.SENTAS.ATTACH.MENT of same specification VB 100 record length. I have also tried using boundary demiliter, but still its not working both together.
Dataset EMAIL.CODE contains:
HELO *******
MAIL FROM:<*******>
RCPT TO: <********>;
DATA
FROM: <******>
TO: <*******>;
SUBJECT: subject data
MIME-VERSION: 1.0
CONTENT-TYPE: TEXT/PLAIN
---Mail Body---
CONTENT DISPOSITION: ATTACHMENT; FILENAME=FILE.TXT
Please suggest me how to send this attachment with body. I have used asterisk due to security reasons. Please feel free to ask if any more information is needed.
In the EMAIL.CODE dataset, you're specifying that content-type of your message is text/plain. However, text/plain on its own (which is the default content type anyway) is always going to appear inline.
In order for the text in the message to be seen as an attachment, you need a Content-Disposition header that specifies attachment.
I can see in your question that you have a CONTENT DISPOSITION line, but it's labeled as being part of the message body. In addition to the fact that it needs to be a header, not a part of the body, it also needs to be hyphenated. So you should have CONTENT-DISPOSITION, not CONTENT DISPOSITION.
However, what all of this gets you is a message containing nothing but the attachment, and your question specifies that you want both a message body and an attachment. In order to do that, your Content-type at the top level needs to be multipart/mixed, and the body of the message needs to contain two MIME parts, one specified simply as being text/plain, and the other also text/plain, but with Content-Disposition: attachment.
This example shows the data for a MIME message containing both a text/plain body and a text/plain attachment.
FROM: <sender#example.com>
TO: <receiver#example.com>
Subject: TESTING message with body and attachment.
Mime-Version: 1.0
Content-type: multipart/mixed; boundary=MIME_BOUNDARY
This is the non-MIME body of a multipart message in MIME format.
Unless you are using a genuinely ancient email client or viewing
the raw source of a message, you should never see this paragraph.
--MIME_BOUNDARY
Content-type: text/plain
This is the inline text section of a multipart message
in MIME format. This is what will appear as the body
of your email when using any normal email client.
--MIME_BOUNDARY
Content-type: text/plain
Content-Disposition: attachment; filename=example.txt
This is the plain-text attachment.
--MIME_BOUNDARY--
.