My Rails 3 application sends out emails in both plain text and HTML formats. I have tested it locally using RoundCube and Squirrel Mail clients and they both display HTML version with images, links, etc. GMail on the other hand chooses plain text format. Any idea what's causing this?
Delivered-To: test#gmail.com
Received: by 10.42.166.2 with SMTP id m2cs16081icy;
Thu, 3 Mar 2011 17:01:48 -0800 (PST)
Received: by 10.229.211.138 with SMTP id go10mr1544841qcb.195.1299200507499;
Thu, 03 Mar 2011 17:01:47 -0800 (PST)
Return-Path: <info#example.com>
Received: from beta.example.com (testtest.test.com [69.123.123.123])
by mx.google.com with ESMTP id j14si1690118qcu.136.2011.03.03.17.01.46;
Thu, 03 Mar 2011 17:01:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of info#example.com) client-ip=69.123.123.123;
Authentication-Results: mx.google.com; spf=neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of info#example.com) smtp.mail=info#example.com
Received: from localhost.localdomain (localhost [127.0.0.1])
by beta.example.com (Postfix) with ESMTP id F3C273A3EC
for <test#gmail.com>; Fri, 4 Mar 2011 01:01:45 +0000 (UTC)
Date: Fri, 04 Mar 2011 01:01:45 +0000
From: info#example.com
To: test#gmail.com
Message-ID: <4d7039f9e9d3e_3449482ab7831658#test.mail>
Subject: Your example account was activated.
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_4d7039f9e6967_3449482ab7831370";
charset=UTF-8
Content-Transfer-Encoding: 7bit
----==_mimepart_4d7039f9e6967_3449482ab7831370
Date: Fri, 04 Mar 2011 01:01:45 +0000
Mime-Version: 1.0
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <4d7039f9e95ed_3449482ab7831519#test.mail>
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
</head>
<body>
<p><img border="0" src="http://example.com/images/logo.png" alt="example logo" /></p>
<p>Congratulations, Test!</p>
<p>
Your <a style="text-decoration:none;color:#ef4923;" href="http://example.com/">example</a> account was activated.
</p>
</body>
</html>
----==_mimepart_4d7039f9e6967_3449482ab7831370
Date: Fri, 04 Mar 2011 01:01:45 +0000
Mime-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <4d7039f9e8b0e_3449482ab78314b7#test.mail>
Congratulations, Test!
Your example.com account was activated.
----==_mimepart_4d7039f9e6967_3449482ab7831370--
Try switching the order of the parts of the message, putting the HTML part after the plain-text part. It might work :).
NOTE: I cannot remember now where I read this (or if I for sure even
did), but the reason switching might help is because I think the
preferred part of the message may be the last part.
Update: I found a place where it says that parts in a multipart MIME message should be in order of increasing preference -- here, in section 7.2.3 (edit: latest version here; thanks #ALEXintlsos!), starting with the third to last paragraph.
Update: Here is a quote of section 7.2.3, (see https://stackoverflow.com/help/referencing):
7.2.3 The Multipart/alternative subtype
The multipart/alternative type is syntactically identical to multipart/mixed,
but the semantics are different. In particular, each of the parts is an
"alternative" version of the same information. User agents should recognize
that the content of the various parts are interchangeable. The user agent
should either choose the "best" type based on the user's environment and
preferences, or offer the user the available alternatives. In general, choosing
the best type means displaying only the LAST part that can be displayed. This
may be used, for example, to send mail in a fancy text format in such a way
that it can easily be displayed anywhere:
From: Nathaniel Borenstein <nsb#bellcore.com>
To: Ned Freed <ned#innosoft.com>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
...plain text version of message goes here....
--boundary42
Content-Type: text/richtext
.... richtext version of same message goes here ...
--boundary42
Content-Type: text/x-whatever
.... fanciest formatted version of same message goes here
...
--boundary42--
In this example, users whose mail system understood the "text/x-whatever"
format would see only the fancy version, while other users would see only the
richtext or plain text version, depending on the capabilities of their system.
In general, user agents that compose multipart/alternative entities should
place the body parts in increasing order of preference, that is, with the
preferred format last. For fancy text, the sending user agent should put the
plainest format first and the richest format last. Receiving user agents should
pick and display the last format they are capable of displaying. In the case
where one of the alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to show that
alternative, an earlier alternative, or both.
NOTE: From an implementor's perspective, it might seem more sensible to reverse
this ordering, and have the plainest alternative last. However, placing the
plainest alternative first is the friendliest possible option when
multipart/alternative entities are viewed using a non-MIME- compliant mail
reader. While this approach does impose some burden on compliant mail readers,
interoperability with older mail readers was deemed to be more important in
this case.
It may be the case that some user agents, if they can recognize more than one
of the formats, will prefer to offer the user the choice of which format to
view. This makes sense, for example, if mail includes both a nicely-formatted
image version and an easily-edited text version. What is most critical, however,
is that the user not automatically be shown multiple versions of the same data.
Either the user should be shown the last recognized version or should
explicitly be given the choice.
Related
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"
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 days ago.
Improve this question
We send e-mail to our users containing URLs with a limited time access token encoded in base64 included via query string. In a small number of cases we are seeing users invoke our site with a different URL than expected. Specifically the values of query string parameters have been altered.
Here is an example of a URL (token is expired by now):
https://example.com?access_token=flWucTdvBvWFHmV4AvVfVaE8dDV9VxcKIDW2.flWjbJDvBvWvMwCxLGB5MF35BJMzYGFkMJVgBGt6ZD35ZmMxLGdkAEZkLGFvYDWyfUBvBwF5ZGZ8BGHlZEZfVzyueDV9ZGLkZwd7AGLjZa3.4WjeBK_dZdtCWk9DeTvDCFhyF6Wkf5BAKdVc1caihkF3xy84M2_EfYEvHMxmyYbgFFjh_K8c42wZJZmWBh84E_ee5TxWyaA_Gbg1TuIuetii4kAa6dfYwTthkFDwbD8W6hV1TAjTGfkDZ35CE-E-HIyGeEj2EJwvtKFzUbLcxcWCZhh-9ilffcfaEeKMFF4Me7ebatcfAkxkeFy7yAvi8etAeMD69BAuxMlb0T2TCfDtUKTazCaFd0t32XwAe61jFuMFaC6dvJ9ELGKLch8YJ8IYIc3AJeC4v4WEHe8wWMVMgmaLKAfvCX--mKBYaxh-ebwKLjdwY3Ke_c1yA2IuBYb8vF9_XFvDvIUFgBM8zeCCH952UvZ6V-BlBev9aK30iLblCXw4F7J0a-_c3YFbFlkfI7eFT4A2bg4DkHuiEEE21DMd5aejueXMdAgX0ehdBMZcj66DTcUD7CJje5cBvZzMxFC8EedE2e66ktFe8Exl8b1d_VYCiEfadBbycheLb5zvk-EzF1CWMbeEAAekAcLBWCEFVAjT6HX3IEZB_YetX80zEKa7VUMvTeFdeXzBE0L-vBDeVb1cEFh2aahccEjIcuAlGLAdagEDGbdt9cgbJ2C6HI92iM9ewB2t4xbbeeZFFVBGUfcKDy7aDyi03_Dw9jLLAFCyDCFj127_U4Z&expires_at=4946228536333
The example is very close to being valid: protocol, host and path are untouched, query string parameter names are correct and the length and type of parameter values is also close to the expected. The value of expiry_at should have been something close to 1613995200000. If you shift all digits individually by 3 you get a value which is likely the original value.
The mails are sent using Nodemailer SMTP transport through SendGrid service. URLs are put together using URLSearchParams from Node.js. I'm reluctant to believe invalid URLs are sent from our systems, since more than 99% of users don't experience this issue. But I have no logging in sufficient detail to know for sure.
I don't have access to detailed information about network or mail filters at my users but I have seen users at the same company with and without the issue. In case this could be caused by some kind of encoding header mismatch, I've included a full example of raw headers and content from one of our e-mails:
Delivered-To: recipient#qvest.io
Received: by 2002:ac0:b64a:0:0:0:0:0 with SMTP id n10csp3067913ime;
Mon, 8 Feb 2021 06:00:04 -0800 (PST)
X-Google-Smtp-Source: ABdhPJzmj9vRTtmN1IvVePlQBoEcReWgLQ0PonOzbLDHRnRc8DxWpGSKidkZ3OZPE6pAMBVTnEbu
X-Received: by 2002:a05:6e02:1b84:: with SMTP id h4mr15215295ili.196.1612792804205;
Mon, 08 Feb 2021 06:00:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1612792804; cv=none;
d=google.com; s=arc-20160816;
b=o6BmAjDW2hu85OH++kbsbsOI77j4muGr6xny8LN4LS0QawzIgSCMrEMMFjWyZKiXwg
pJNiyxIKBEP4hfWRBB4aDGNjAi6LROvCYX9mTZG8f5Yx5kd9U8gh5dhDLWQPTxh8Ix1h
CW7Aan0v7E3TzHDTDV/HmmOqY6cbx+d8QZujuswankoPdqSIOkGPp7FlaO617C82z5Ce
HIlTmKPXFngSkVW98UxtnGtvAjWuwpcMqOkIOHLJspfW183lDHBfg6ZOqQrWIfdGvet3
Wr9kgvABU88bjqa41/LonF28jm88n4nI/5QYJVQGmQV7ELNVbWFZGaeO1m+J+ellFZ9h
FHwA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:to:reply-to:mime-version:date
:content-transfer-encoding:message-id:subject:from:dkim-signature;
bh=QQMlgBEIEaxfQJ5P0N6Esf+zceZ2+qccFfw1P3Vcra0=;
b=IOj2OtO9nFaNkW8JelpoEe9NHJEBIZnKn2HOqEbE9D95YwH0VqPzQn0dScsZJs6YCf
aj8gbOzAj2m68GSBMtPN+9YbauZR+1Ygo+qxSGzjtngk71e+oGcfNJuoxQNS3qWJ4I8y
O44MEFNZx/yIRsl8Sj1PMwkOgyi1NLLJGoRSLv2TGgDxfJXsqj/5IiDlhBESy0ONDuL1
ZWz0Revg4BpcJ3dI0eqf0ljtiUQSAyn1fFi/+JHUBM5/oXqmW0LL1QRHxZte7d11NW8t
Rs2K0RpuFMdZFzf/vhE5qvCxtGJokqQoOwWH7zfyPka+2CMaH3VV/DpMRL/txrp89yH2
qy+g==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=#qvest.io header.s=s1 header.b=LnUXPA7s;
spf=pass (google.com: domain of bounces+6645413-7961-recipient=qvest.io#em9402.qvest.io designates 168.245.121.57 as permitted sender) smtp.mailfrom="bounces+6645413-7961-recipient=qvest.io#em9402.qvest.io";
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=qvest.io
Return-Path: <bounces+6645413-7961-recipient=qvest.io#em9402.qvest.io>
Received: from o1.notify.qvest.io (o1.notify.qvest.io. [168.245.121.57])
by mx.google.com with ESMTPS id o9si15771544ilu.103.2021.02.08.06.00.03
for <recipient#qvest.io>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 08 Feb 2021 06:00:04 -0800 (PST)
Received-SPF: pass (google.com: domain of bounces+6645413-7961-recipient=qvest.io#em9402.qvest.io designates 168.245.121.57 as permitted sender) client-ip=168.245.121.57;
Authentication-Results: mx.google.com;
dkim=pass header.i=#qvest.io header.s=s1 header.b=LnUXPA7s;
spf=pass (google.com: domain of bounces+6645413-7961-recipient=qvest.io#em9402.qvest.io designates 168.245.121.57 as permitted sender) smtp.mailfrom="bounces+6645413-7961-recipient=qvest.io#em9402.qvest.io";
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=qvest.io
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qvest.io; h=content-type:from:subject:content-transfer-encoding:mime-version: reply-to:to:list-unsubscribe; s=s1; bh=QQMlgBEIEaxfQJ5P0N6Esf+zceZ2+qccFfw1P3Vcra0=; b=LnUXPA7swjX2NjzJ2TvETSJY5VT80AbEjWSwNcMYGw4MkfSYzVcaRAFwpmyp1G2scMg0 /OFqLVBN86MCPcybH+vVREbdOGcPEMIxaS5nAHMMwDCsXJE8IUe4+CiKwHXM9zMd676d+D ymYO442JwLoOBz22iAFyRjX56z8Sw4HiA=
Received: by filterdrecv-p3mdw1-689c95dc44-9222s with SMTP id filterdrecv-p3mdw1-689c95dc44-9222s-20-602143E2-164
2021-02-08 14:00:02.769325447 +0000 UTC m=+418785.634806042
Received: from [127.0.0.1] (unknown) by ismtpd0004p1lon1.sendgrid.net (SG) with ESMTP id wSs4J7aLQt-9UHbZ3GKoTg for <recipient#qvest.io>; Mon, 08 Feb 2021 14:00:02.608 +0000 (UTC)
Content-Type: text/html; charset=iso-8859-1
From: "Qvest" <noreply#qvest.io>
Subject: Subject
Content-Transfer-Encoding: quoted-printable
Date: Mon, 08 Feb 2021 14:00:02 +0000 (UTC)
MIME-Version: 1.0
Reply-To: "Qvest Support" <support#qvest.io>
To: Recipient <recipient#qvest.io>
<!DOCTYPE html>
<html xmlns=3D"http://www.w3.org/1999/xhtml">
<head>
<meta charset=3D"UTF-8">
<meta http-equiv=3D"x-ua-compatible" content=3D"ie=3Dedge">
<title>Title</title>
<meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=
=3D1">
</head>
<body>
<a href=
=3D"https://example.com?access_token=eyJhbGciOiJSUz=
I1NiIsInR5cCI6IkpXVCJ9.eyJwaWQiOiI5ZDE0MTc5Ni02YTEyLTExZWItOWY4YS01N2IyN2U2=
NTczMGIiLCJleHAiOjE2MTQwMDI0MDMsImlhdCI6MTYxMjc5MjgwMn0.t7km4fdjgRHvggNcPFi=
mZZzwFsvhvBaUlD2q0MEvKRtEOSDcs6oZ_vt2A9A0qNKk_hhLCFhZbaXaRjexsr4b8-XCEiRrPE=
atLSq0EcE9P3W2kqyut4_8_2Apvm03fiR6gQkfQXwosfHVPT3aULtQ_xUyRNydG10ChTM-hfYtD=
yvavPivP9gpN82pSzMk4DBR_HztHEFDGbbgDnzQ6d_j4kj8bcQXGdWTlw_eefA7H9i7WqvD_6pK=
LsaEjODCt7Ys4UIRBKvhulFfatdQXTOnXvMoIUIjavHHbDrTaZKr53P5DHRsZXPhDGMXjxYfbhk=
GmoFALLGgwxmwNpkVMJaDLH1EyQ_avo9TXjtEcoPVXd3vWddoYEpX5QcOrK1O1NYCS8A_KQiRcZ=
ZMAujzRs65SJ--NQUPKr1_jwfcRgcUwB-10nJjet1G0U2uajDktlc5uqE9aqW7Mnhxn9pJ8WqUE=
eIrnViqCYfAAyAZRMqneJi9WOmaYm4DohkZHQ0er6Z4gsRDIV8Dwy4vFCwbrNvw2PWuVTh7R9U8=
Nu784UOFyzDUw2HRDEJVqXYp-4VgmSlF5GG8h9TFVTrSycA7hr2K46RXidGIHLbeHp6twiN7_pO=
7uRqAzrGBcaXb4Xf0HEp1TpHOFK3AJyMHdda_lGB_X_Ht2LBWT4mPaN7OJBi1-xg&expire=
s_at=1614002403000">this link</a>
</html>
TL;DR: It's users that have Microsoft Advanced Threat Protection enabled on their account or domain.
I was having the exact same problem with a base64-encoded JSON string being corrupted in the same way, check out my investigation here, I have collected a bit more information that correlates with yours.
I've send 2 emails to Microsoft's NOC/Abuse contacts, no response yet.
Regarding the other answers:
Broken Email client and/or bad header encoding explanations are very unlikely, because these requests are coming exclusively from Microsoft-owned IP addresses. I've collated and verified (I have a list of 6,924 subnets and 11,043 IP addresses of visits.
In addition, per my analytics tracking, these sessions do not have any human activity associated with them after the visit. I.e. I have an error page that invites them to send me a message for support, no one ever has (out of 11000+ requests), however with other issues I do get support requests from users.
as I read on the official rfc2822
The "Message-ID:" field provides a unique message identifier that
refers to a particular version of a particular message. The
uniqueness of the message identifier is guaranteed by the host that
generates it (see below). This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A message
identifier pertains to exactly one instantiation of a particular
message; subsequent revisions to the message each receive new message
identifiers.
Note: There are many instances when messages are "changed", but those
changes do not constitute a new instantiation of that message, and
therefore the message would not get a new message identifier. For
example, when messages are introduced into the transport system, they
are often prepended with additional header fields such as trace
fields (described in section 3.6.7) and resent fields (described in
section 3.6.6). The addition of such header fields does not change
the identity of the message and therefore the original "Message-ID:"
field is retained. In all cases, it is the meaning that the sender
of the message wishes to convey (i.e., whether this is the same
message or a different message) that determines whether or not the
"Message-ID:" field changes, not any particular syntactic difference
that appears (or does not appear) in the message.
An email message can hold the same ID in some particular cases.
For example, take a look at the two following message header:
Return-Path: <xxx.xxx#xxx.it>
Received: from relaypsm.eng.it (xxxx.xxx.it [xxx.xxx.xxx.xxx])
by xxxxx-xxx.xxxxx.it (8.14.4/8.14.4) with ESMTP id v0PJ6wOD014924
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL)
for <xxxxx#xxx.xxxxx.it>; Wed, 25 Jan 2017 20:06:59 +0100
X-Icontrol: Sent by Inrete Icontrol
Received: from MailAV (unknown [xxx.xxx.xxx.xxx])
by deliver (Postfix) with ESMTP id 52B743A4
for <xxxxx#xxx.xxxxx.it>; Wed, 25 Jan 2017 20:06:58 +0100 (CET)
Received: from LBURRINIW (unknown [192.168.63.9])
by xxxxx.xxx.it (Postfix) with ESMTPSA id 8D80339F
for <xxxxx#xxx.xxxxx.it>; Wed, 25 Jan 2017 20:06:51 +0100 (CET)
From: "Luca Burrini" <luca.burrini#eng.it>
To: <xxxxx#xxx.xxxxx.it>
References:
In-Reply-To:
Subject: fatture xxxxx
Date: Wed, 25 Jan 2017 20:06:51 +0100
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAHCgtCXXdtBNl+uXnP8eDHPCgAAAEAAAAGutlHZJGkpAhmPV6f+ofh8BAAAAAA==#eng.it>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_00D6_01D27746.91533090"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdCOWOCYZlK03GM4S5Cd5xo9GuRjGAAorxQwBlBUrvAFQ/QDgAew8EzACjCMyCAGU/qYMAV4vr+QBuilgWAKzjrI4AagZVDwBqrsgiAABfH4YAXsTykQBafYYmAEIBNvwBSv7j/wBgnvoHAB0wKvkAWE5BHA
Content-Language: it
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: not scanned, disabled by settings
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2017/01/25 14:07:00 #8842754
X-KLMS-AntiVirus-Status: Clean, skipped
X-IControl-Milter-Checked: yes (IControlServer: xxxxx-NEW SrcIpType: UnTrusted SrcIpHeaderType: Undefined Authenticated: no)
X-IControl-Milter-SPF-Checked: yes (IControlServer: CEDACRIPEC1-NEW HeloSPFType: none FromSPFType: pass HeloHeaderSPFType: Undefined FromHeaderSPFType: pass)
X-IControl-Milter-MD5SUM: c803ab2c6498f91967e8cb2f5954f43a
and
Return-Path: <xxx.xxx#xxx.it>
Received: from xxxxx.xxx.it (xxxxx.xxx.it [xxx.xxx.xxx.xxx])
by xxxxx-new.xxxxx.it (8.14.4/8.14.4) with ESMTP id uBSGqOAP023446
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL)
for <xxxxx#xxx.xxxxx.it>; Wed, 28 Dec 2016 17:52:24 +0100
X-Icontrol: Sent by Inrete Icontrol
Received: from MailAV (unknown [161.27.15.23])
by deliver (Postfix) with ESMTP id A0FD33AC
for <xxxxx#xxx.xxxxx.it>; Wed, 28 Dec 2016 17:52:23 +0100 (CET)
Received: from LBURRINIW (unknown [xxx.xxx.xxx.xxx])
by relaypsm.eng.it (Postfix) with ESMTPSA id 7D2D83CC
for <xxxxx#xxx.xxxxx.it>; Wed, 28 Dec 2016 17:52:17 +0100 (CET)
From: "Luca Burrini" <xxx.xxxxx#xxx.it>
To: <xxxxx#xxx.xxxxx.it>
References:
In-Reply-To:
Subject: fatture xxx
Date: Wed, 28 Dec 2016 17:52:16 +0100
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAHCgtCXXdtBNl+uXnP8eDHPCgAAAEAAAAGutlHZJGkpAhmPV6f+ofh8BAAAAAA==#eng.it>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0092_01D26133.2135B540"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdCOWOCYZlK03GM4S5Cd5xo9GuRjGAAorxQwBlBUrvAFQ/QDgAew8EzACjCMyCAGU/qYMAV4vr+QBuilgWAKzjrI4AagZVDwBqrsgiAABfH4YAXsTykQBafYYmAEIBNvwBSv7j/wBgnvoHAB0wKvkA==
Content-Language: it
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: not scanned, disabled by settings
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/12/28 09:52:00 #8723401
X-KLMS-AntiVirus-Status: Clean, skipped
X-IControl-Milter-Checked: yes (IControlServer: CEDACRIPEC1-NEW SrcIpType: UnTrusted SrcIpHeaderType: Undefined Authenticated: no)
X-IControl-Milter-SPF-Checked: yes (IControlServer: CEDACRIPEC1-NEW HeloSPFType: none FromSPFType: pass HeloHeaderSPFType: Undefined FromHeaderSPFType: pass)
X-IControl-Milter-MD5SUM: 30378f3a90c4e4051ecd9eab79feaa02
They hold the same ID but the two emails, trust me, belong to different transmissions. In addition they hold different attachments.
Can you tell me why the email IDs are the same?
You can get different messages with the same message-Id. Here's how:
Message-Id 1 is generated when user A sends message1 to B and C.
B is a final destination, which accepts the message and stores it.
C is a mailing list. The mail message is held for moderation. At some later point in time, the mail list moderator accepts the message. The message is modified with the header and footer of the mailing list and sent out. B is on the mailing list and receives a copy.
Now B has two copies of message1, one without the mailing list info, one with it.
I'll take a shot at this.
RFC 822 specifies that:
"The uniqueness of the message identifier is guaranteed by the host which generates it."
It also specifies under section 4.2:
Some systems permit mail recipients to forward a message,
retaining the original headers, by adding some new fields. This
standard supports such a service, through the "Resent-" prefix to
field names.
So:
It sounds like the host email program is not changing the said ID.
message-id is optional, but ESMTP indicates that servers should add
it if missing during a transaction. (https://www.rfc-editor.org/rfc/rfc2821)
forwarding messages SHOULD add "resent-", but that's up to the code within the client/server.
The ESMTP ID change seems to indicate different email servers... and the subject's typo feels contrived, even spam-like. (isn't "fatture Engineering" a mixture of Italian and English for "Engineering Invoice"?)
If it's spam, I'd expect message IDs to be similar even if they're coming from the same server since they are, in fact, the same message.
Do you have more information about the purpose/content of this email?
I'm trying to build up my own Email sending class and it seems I have a bug with my MIME.
If someone could find the error or tell me about a working MIME Validator I would really appreciate that.
Thanks in advance
JD
To: me#mydomain.com
Subject: Test Alternate
X-PHP-Originating-Script: 1000:SendMail.class.php
MIME-Version: 1.0
From: me#mydomain.com
Content-Type: multipart/mixed;
boundary="MultipartMail53dfa8ade817e"
Message-Id: <20140804153717.EA93E160195#myDevice>
Date: Mon, 4 Aug 2014 17:37:17 +0200 (CEST)
X-RCPT-TO: <me#mydomain.com>
Status:
X-UIDL: 706801872
X-IMail-ThreadID: c9b40003d631c851
--MultipartMail53dfa8ade817e
Content-Type: multipart/alternative;
boundary="Alternative53dfa8ade8378"
--Alternative53dfa8ade8378
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Some Text content
--Alternative53dfa8ade8378
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Das ist Text
--
Text
*Some more Text*
Text
--Alternative53dfa8ade8378--
--MultipartMail53dfa8ade817e--
There's a few things "wrong" with your email:
Firstly, you have a non-header in your header:
To: me#mydomain.com
*Test Alternate*
X-PHP-Originating-Script: 1000:SendMail.class.php
(*'s around the broken bit)
Secondly, (and probably your main issue with Thunderbird) is that your multipart/alternative has the child parts in the wrong order. The way that multipart/alternative is supposed to work is that the last part is supposed to be the form that is closest to what the original author of the message intended for you to see (IOW what he/she saw in their WYSIWYG editor).
TL;DR
Put the text/html part last and the text/plain part first within the multipart/alternative.
I learning Perl and doing a home made project to my family (a subscription project). The Perl application that uses Net::POP3 connect to my mailbox and save all my emails to a file (Mail.txt). When I open this file I see a lot of junk, as below. What i can do to remove this? Thanks.
Return-Path:
Received: from [unix socket] by embro.tpn.terra.com (LMTP); Sun, 11 Oct 2009 04:09:50
+0000 (UTC)
X-Abaca-Spam: 153
X-Terra-Karma: -2%
X-Terra-Hash: 2c7d32f717e807b11af5c0871edb9e93
Received-SPF: pass (embro.tpn.terra.com: domain of linuxquestions.org designates
208.101.3.244 as permitted sender) client-ip=208.101.3.244;
envelope-from=forum#linuxquestions.org; helo=sql02.linuxquestions.org;
Received: from sql02.linuxquestions.org (smtp.linuxquestions.org [208.101.3.244])
by embro.tpn.terra.com (Postfix) with ESMTP id 14EA1580000A2
for ; Sun, 11 Oct 2009 04:09:49 +0000 (UTC)
Received: from web02.linuxquestions.org (web02-be.linuxquestions.org [10.13.156.4])
by sql02.linuxquestions.org (8.13.8/8.13.8) with ESMTP id n9B49mXe005694
for ; Sun, 11 Oct 2009 00:09:48 -0400
DomainKey-Signature: a=rsa-sha1; s=smtp; d=linuxquestions.org; c=simple; q=dns;
b=Le/RccpkHMfH426hLwlLkIbCujr0LiWKM32ryuZ1fWwYU6VjCTocd30N/JAg+w77d
54VJkNnpA18iQxJ/yfKyQ==
Received: from web02.linuxquestions.org (localhost.localdomain [127.0.0.1])
by web02.linuxquestions.org (8.13.8/8.13.8) with ESMTP id n9B49m2f027957
for ; Sun, 11 Oct 2009 00:09:48 -0400
Received: (from nobody#localhost)
by web02.linuxquestions.org (8.13.8/8.13.8/Submit) id n9B49mNn027956;
Sun, 11 Oct 2009 00:09:48 -0400
Date: Sun, 11 Oct 2009 00:09:48 -0400
To: nathanpc#terra.com.br
Subject: "What programs would you like to see ported to Linux?" update
From: "LinuxQuestions.org"
Auto-Submitted: auto-generated
Message-ID:
X-Priority: 3
X-Mailer: LQ Mailer
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Status: O
Dear nathanpc,
It's not junk. It's email header. Use, for example, Mail::Message to parse it. Something like this:
my $msg_obj = Mail::Message->read($rawdata); my $body = $msg_obj->body;
You know, I did recommend Mail::POP3Client which abstracts away the details:
Body( MESSAGE_NUMBER )
Get the body of the specified message, either as an array of lines or as a string, depending on context.
BodyToFile( FILE_HANDLE, MESSAGE_NUMBER )
Get the body of the specified message and write it to the given file handle.
Email headers consist of all text up to the first completely blank line. So, if you actually do want to throw them away (rather than using a good module to parse them as the earlier examples suggested), just throw away everything up to and including the first blank line.
If you're looking at an mbox-format mailbox file containing multiple messages, you can identify the start of the next message's headers by looking for a line which starts with the five characters "From " (note the trailing space - this is what distinguishes it from a "From:" header).