whats algorithm of Exim message ID [closed] - email-headers

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
i want know a message id in Exim how to generate.
for example : 1YSWPk-0000oX-0N
also Message id in headers
Message-ID: <aa1e23e76be8b95bc21718a4c4e000fc#example.com>
and can decode these?
and any relationship with these and other email headers?

Exim's specification part 3.4 says that
The first six characters of the message id are the time at which the
message started to be received, to a granularity of one second. That
is, this field contains the number of seconds since the start of the
epoch (the normal Unix way of representing the date and time of day).
After the first hyphen, the next six characters are the id of the
process that received the message.
There are two different possibilities for the final two characters:
If localhost_number is not set, this value is the fractional part of
the time of reception, normally in units of 1/2000 of a second, but
for systems that must use base 36 instead of base 62 (because of
case-insensitive file systems), the units are 1/1000 of a second.
If localhost_number is set, it is multiplied by 200 (100) and added to
the fractional part of the time, which in this case is in units of
1/200 (1/100) of a second.
Here are the headers of message sent from my exim to the gmail.com.
Lines 19-27 are generated by my MTA/exim while all lines above are generated by gmail servers.
1 Delivered-To: kondybas#gmail.com
2 Received: by 10.27.143.12 with SMTP id r12csp943315wld;
3 Tue, 3 Mar 2015 12:49:41 -0800 (PST)
4 X-Received: by 10.180.126.69 with SMTP id mw5mr50725522wib.12.1425415780590;
5 Tue, 03 Mar 2015 12:49:40 -0800 (PST)
6 Return-Path: <root#domain.tld>
7 Received: from domain.tld (relay.domain.tld. [11.22.33.44])
8 by mx.google.com with ESMTPS id y2si3224153wjy.199.2015.03.03.12.49.40
9 for <kondybas#gmail.com>
10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
11 Tue, 03 Mar 2015 12:49:40 -0800 (PST)
12 Received-SPF: pass (google.com: domain of root#domain.tld designates 11.22.33.44 as permitted sender) client-ip=11.22.33.44;
13 Authentication-Results: mx.google.com;
14 spf=pass (google.com: domain of root#domain.tld designates 11.22.33.44 as permitted sender) smtp.mail=root#domain.tld;
15 dkim=pass header.i=#domain.tld
16 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=domain.tld; s=s;
17 h=Date:From:Message-Id:Subject:To; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
18 b=p7JbGnGFvxdvL0UESIprvXTXq1GcQTeWZOTy3nrTOynwqHz9JEKQu+nqNU6iZtC7LxmPBbOFXjy3Qbg9vH3BLdaqivk/duFSUoYenFQgQd/iaoZ8sBP3lWXx/Uz6yIy7zH2ySOZO5M/NKfG2QqZsJ8PCChJ01mCSe6bqHfcywbrAi2ZJWws3Kt3lAGIxHkdOjhcCsljrirGCCeYc8WI8PQ==;
19 Received: from root by domain.tld with local (Exim 4.85 (FreeBSD))
20 (envelope-from <root#domain.tld>)
21 id 1YStl5-00010z-JV
22 for kondybas#gmail.com; Tue, 03 Mar 2015 22:49:39 +0200
23 To: kondybas#gmail.com
24 Subject: test
25 Message-Id: <E1YStl5-00010z-JV#domain.tld>
26 From: Charlie Root <root#domain.tld>
27 Date: Tue, 03 Mar 2015 22:49:39 +0200

Related

Url query string values corrupt after being sent in email [closed]

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.

Why 'Received' header fields are missed in Outlook message?

I use EWS GetItem endpoint in order to get MIME content of e-mail message in Outlook. As a rule several 'Received' header fields are present at the beginning of message content. For example:
Received: from AM6PR04CA0035.eurprd04.prod.outlook.com
(2603:10a6:20b:92::48) by AM6PR10MB2789.EURPRD10.PROD.OUTLOOK.COM
(2603:10a6:20b:ac::25) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Thu,
10 Sep 2020 11:36:56 +0000 Received-SPF: Pass
(protection.outlook.com: domain of alterdomus.com designates
51.137.107.73 as permitted sender) receiver=protection.outlook.com; client-ip=51.137.107.73;
helo=smtpworker-in-9.xware-europe-west-1.o365.crossware.co.nz;
Received: from VI1PR10MB3616.EURPRD10.PROD.OUTLOOK.COM
([fe80::204a:2512:2ac2:d5ef]) by VI1PR10MB3616.EURPRD10.PROD.OUTLOOK.COM
([fe80::204a:2512:2ac2:d5ef%3]) with mapi id 15.20.3305.031; Tue, 25 Aug 2020
17:51:53 +0000
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
(104.47.4.57) by
smtpworker-in-9.xware-europe-west-1.o365.crossware.co.nz with
Crossware for Office365; Thu, 10 Sep 2020 11:36:46 +0000
However in some cases those 'Received' fields are missed for some messages. As far as I understand this field is very important for spam detection. It contains information about the sender, the receiver and the received time of a message. This header is added by the receiving mail server as the top line. Depending on the number of mail servers involved, several 'Received' header fields may be included.
What can be the reason of missed 'Received' header fields inside e-mail MIME content? What does it mean?
Not all messages that are in a Office365 mailbox will have been routed via the Transport stack (most will). One example is the MyAnalytics Messages, the Office365 substrate generates these messages and they are created directly in the Mailbox by the substrate rather then being delivered. You can use something like the Message Header analyzer to check https://appsource.microsoft.com/en-us/product/office/WA104005406?src=office&corrid=f7f9ed61-d151-4fcf-b0e2-9e3dec4a92d2&omexanonuid=034f54c1-a89b-429c-adc3-526f6f024f80&referralurl=https%3a%2f%2fwww.google.com%2f to check the headers it grabs the PidtagTransportheaders property https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtagtransportmessageheaders-canonical-property which is a more reliable way of getting the headers then trying to parse it back out of the Mime Message

Same Message ID with with different email

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?

GMail displays plain text email instead HTML

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.

How do I remove email headers?

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).