What is the minimum size in bytes of a valid email (not programming language specific)
standalone raw text (no attachments just to, subject, and body of 1 byte)
sent over SMTP (protocol overhead + email size)
received via POP3 (protocol overhead + email size)
received via IMAP (protocol overhead + email size)
mime multipart as first case, but with two bodies for text/plain and text/html and an attachment body with a 1 byte file
So I just went through a tutorial to answer part of this question about the format / structure of a basic email. I started with the following command
$ nc -C {smtp-server-fqdn} 25
Here is a dump of the conversation {parametrized with secrets omitted}
220 {smtp-server-fqdn} ESMTP
EHLO {yourdomain.ext}
{smtp-server-fqdn}
250-PIPELINING
250-SIZE 40960000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
HELO {yourdomain.ext}
250 {smtp-server-fqdn}
AUTH LOGIN
334 VXNlcm5hbWU6
{username|base64}
334 UGFzc3dvcmQ6
{password|base64}
235 2.7.0 Authentication successful
MAIL FROM: <someone#sender-fqdn>
250 2.1.0 Ok
RCPT TO: <someone#recipient-fqdn>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "{VanitySenderName}" <someone#sender-fqdn>
To: "{VanityRecipientName}" <someone#recipient-fqdn>
Subject: {subject}
Date: {date}
{message body}
.
250 2.0.0 Ok: queued as {identifier}
QUIT
221 2.0.0 Bye
<ctrl>+<c>
So to break this down
Email payload itself (following line after DATA until .) takes a minimum of 75 bytes
From: <a#b>
To: <a#b>
Subject: c
Date: Sat, 20 Apr 2019 13:25:00 +0100
d
.
Honestly this is barely a valid email. It does have two additional fields to the minimum as per https://www.rfc-editor.org/rfc/rfc5322#page-21 It's a from, to, subject, date and body. If any of these were missing, I think your email provider should reject them.
The actual body I sent to test this with my real email and a provider (dreamhost) was 151 bytes because the emails were real and the domain was longer than a character.
More interestingly the envelope took this to 468 bytes (for the real email with auth not including server responses), but theoretically could be smaller (146 bytes with single character domain with no extension, only good for lab + internal)
EHLO c
HELO c
AUTH LOGIN
a
b
MAIL FROM: <a#b>
RCPT TO: <a#b>
DATA
From: <a#b>
To: <a#b>
Subject: c
Date: Sat, 20 Apr 2019 13:25:00 +0100
d
.
QUIT
It's < 1KB so fit for embedded, but is also missing transport overhead, and missing several features, such as multi-part support.
All you'd need to do to use this is equip yourself with a socket library to open the connection, base64 encoder (for plain user + password), a date string generation utility and rudimentary command-line skills.
This is by no means a complete answer, but it answers two of the cases with necessary caveats for the understanding of a beginner, getting to grips with the technology.
This doesn't seem to be a a programming question, right? Might want to clarify, or it'll be closed.
Tens of bytes in each case. 40-45 bytes for the minimal valid message, closer to 100 with an attachment. Some depend on how you're counting, e.g. when the message is 50 bytes, whether you include the bytes for the IMAP/POP login process matters a great deal.
Date: 0:00:00 1 May 2019 -0000
From: a#l.is
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"
I am looking to encrypt certain mail headers (Subject and Reply-To) which are being sent in an encrypted mail.
I am taking an entire MIME (Headers included) and successfully encrypting it.
I can send this S/MIME encrypted mail to my mail client (Thunderbird) successfully. It will be successfully decrypted and verified as signed.
However, any headers that are sent in the inner encrypted MIME are not being used by my mail client.
According to RFC-5751 I should be wrapping my mail in a message/rfc822 message but I am at a loss at how to achieve this.
Below are examples of my messages that I am creating.
My first question is, is the last MIME that I am creating the message/rfc822 correctly structured?
Is this possibly an issue with the mail client?
Can I event encrypt the Reply-To Header?
If I could get an example of a mesage/rfc822 encapsulated message that would be really helpful.
Mail to be encrypted
This will successfully result in a received mail that is signed and the Subject / Reply-To headers are interpreted correctly by the mail client.
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
From: sender#domain.com
Sender: senderdomain.com
To: recipient#domain.com
Reply-To: keepsecret#domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
My Message that will be encrypted
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIOCAYJKoZIhvcNAQcCoIIN+TCCDfUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gguTMIIFCDCCA/CgAwIBAgIQVz2HAGYJcTJNsPiWLx1f/TANBgkqhkiG9w0BAQsFADCBjTELMAkG
.
.
.
17p13e02JxfyCqltdb6lkOdpRZ6ZlHHuQZyBCuRtJhRN83gvcJ4d7WCxKI349NEa2/tOb8ziFGat
gzvgu+o=
----_NmP-d017e0e3556f7bbc-Part_1--
My Encrypted Mail
This encrypted mail will be received and successfully decrypted and verified (signature verified) by my mail client. Reply-To and Subject are still working as expected as they are still visible. Note: all the headers from the unencrypted mail are all still present inside the encrypted body of this message.
Sender: sender#domain.com
From: sender#domain.com
To: recipient#domain.com
Subject: A Secret Subject
Reply-To: keepsecret#domain.com
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Date: Mon, 24 Feb 2020 16:03:38 +0000
MIME-Version: 1.0
MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
O+EPVCh1fGDFwiFpDtY/z1Lv8g==
My Encapsulated message/rfc822
This message will be decrypted correctly but my client does not recognise that it was an encrypted message or verify that it was signed (Not worried about that so much). The decrypted mail is interpreted as forwarded and attached as an .eml file. However, no Subject or Reply-To headers found (they are in the encrypted mail). If I add dummy values as recommended by the RFC, those dummy values will be used by my mail client, not the encrypted ones.
Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: sender#domain.com
Sender: sender#domain.com
To: recipient#domain.com
Date: Mon, 24 Feb 2020 15:28:07 +0000
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
MIME-Version: 1.0
----_NmP-07c15c542cedfe74-Part_1
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
fYU1LuhSBEyymSVRzwWr2T3lrhUe5BZBoY996epZtOPdIYrz2jqUglii1+AUBpUP
UUnpr8+cHTMk/50LHdy3MqMeYA==
----_NmP-07c15c542cedfe74-Part_1
Edit: add excerpt from RFC
In RFC-8551 it states the following
In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header
fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header. Given
the security difference between headers, it is RECOMMENDED that the
receiving client provide a distinction between header fields,
depending on where they are located.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account
header-merging issues as previously discussed.
RFC 822 provides a generalized description of how message headers of an email are composed and should be treated by systems they are transmitted through. RFC 5751 S/MIME 3.2 (btw, obsoleted by it successor RFC 8551 S/MIME 4.0) describes details how to use that standard to create encrypted emails.
So your approach to encrypt an email as described under My Encrypted Mail is valid and correct.
However, your approach as described under My Encapsulated message/rfc822 is not quite correct. You have obviously misinterpreted the RFC with regard to how to apply the rfc822 wrapper. The wrapper needs to be around your message before it gets encrypted, so it's going to be inside the encrypted part.
In your example, the unencrypted message (a slightly modified version Mail to be encrypted) would have to look like this:
MIME-Version: 1.0
Content-type: message/rfc822
From: sender#domain.com
Sender: senderdomain.com
To: recipient#domain.com
Reply-To: keepsecret#domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
My Message that will be encrypted
[...]
So you basically add the message/rfc822 to the message before it gets encrypted.
I have been able to verify this approach and tested the resulting message in two receiving mail clients with different results. With the macOS Mail application, the encrypted subject was not used to replace the unprotected "outer" subject, but at least, it was displayed prominently below the original headers. This is compliant with the RFC which is not very specific about the presentation:
It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. Given the security difference between headers, it is RECOMMENDED that the receiving client provide a distinction between header fields, depending on where they are located.
An encrypted Reply-To header is displayed similarly, but it's email address is not honored when replying to that email.
Client Support
The support for encrypted headers in clients is somewhere between weak and non-existent. The results of some tests:
No client supports replacing the "outer" headers by the "inner" encrypted ones
Apple Mail (macOS) displays the inner headers prominently within the message
Thunderbird displays the encrypted part including its headers as a forwarded message
Outlook does not display the encrypted part, but instead confusingly displays just an empty message with an attachment (which is the encrypted message)
Alternative approaches
There is a seemingly promising approach proposed in this draft for Protected Headers for Cryptographic E-mail (work in progress). The idea is to include the protected headers as a separate part in a multipart message. This part will be rendered inline by agnostic clients, while at the same time, it can be properly processed by supporting clients.
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?
When sending an email, the recipient list is given during the SMTP dialogue through RCTP TO: command. Later, in DATA command, header fields like 'To', 'Cc','bcc' are indicated. Does this RCPT TO list of recipients have to match with the headers indicated in DATA command?
Also, if the recipient is not indicated in RCPT TO, but in the To field of email header, is it going to be delivered to the recipient not in RCPT TO?
No, they don't have to match. When the message is sent, the SMTP Server (aka Message Transfer Agent or MTA) is creating a so called SMTP envelope which contains the recipients and the sender of the message (see RFC5321):
SMTP transports a mail object. A mail object contains an envelope and content. The SMTP envelope is sent as a series of SMTP protocol
units (described in Section 3). It consists of an originator
address (to which error reports should be directed), one or more
recipient addresses, and optional protocol extension material.
It is, actually, quite often that the RCPT TO: Command has more recipients that the header of the message - one common case is the usage of "blind copies" bcc: (see RFC5321):
Addresses that do not appear in the message header section may appear
in the RCPT commands to an SMTP server for a number of reasons. The
two most common involve the use of a mailing address as a "list
exploder" (a single address that resolves into multiple addresses) and
the appearance of "blind copies".
Does this RCPT TO list of recipients have to match with the headers
indicated in DATA command?
Nope.
if the recipient is not indicated in RCPT TO, but in the To field of
email header, is it going to be delivered to the recipient not in RCPT
TO ?
The RCPT. Here's a (modified) transcript from my own SMTP client where I do just what you ask:
CLIENT: MAIL FROM:<myaccount#gmail.com>
SERVER: 250 2.1.0 OK
CLIENT: RCPT TO:<myaccount#gmail.com>
SERVER: 250 2.1.5 OK
CLIENT: DATA
SERVER: 354 Go ahead
CLIENT: Subject: Test email
CLIENT: From:'John Doe'<fakeaccount#gmail.com>
CLIENT: To:'John Doe'<fakeaccount#gmail.com>
CLIENT: This is a test...
CLIENT: .
The message was successfully sent to "myaccount#gmail.com".
SMTP protocol (RFC 2821) states the following:
When RFC 822 format [7, 32] is being used, the mail data include the
memo header items such as Date, Subject, To, Cc, From. Server SMTP
systems SHOULD NOT reject messages based on perceived defects in the
RFC 822 or MIME [12] message header or message body.
And this:
The DATA command can fail at only two points in the protocol
exchange:
If there was no MAIL, or no RCPT, command, or all such commands
were rejected, the server MAY return a "command out of sequence"
(503) or "no valid recipients" (554) reply in response to the DATA
command. If one of those replies (or any other 5yz reply) is
received, the client MUST NOT send the message data; more
generally, message data MUST NOT be sent unless a 354 reply is
received.
From these statements, the headers and RCPT TO: command content does not have to match (altough they should match), and not using RCPT TO: MAY result in an error to prevent proceeding with DATA command.
I'm trying to sort out an opt in mailing list system. I understand the basic principles and design required but i'm having an issue with it being picked up as spam.
If i send a html email through outlook through email#domain.com it works fine and is not treated as spam. When i use the Zend_mail object to send mail it sends but is treated as spam on the test emails accounts i'm sending it too.
This is the code im using to send an email item.
//send an email
$mail = new Zend_Mail();
$config = array('auth' => 'login','username' => 'email#domain.com','password' => 'mypassword');
$transport = new Zend_Mail_Transport_Smtp('mail.domain.com', $config);
$mail->setSubject($item->title);
$mail->setFrom("email#domain.com");
$mail->addTo($item->email, $item->forename);
//$mail->setBodyText($item->contentPlain);
$mail->setBodyHtml($item->contentHTML);
$mail->send($transport);
As you can see im using the smtp transport object to authenticate but it still seems to treat this as spam. Anyone with pointers or tips is very much appreciated!!
Header info from the email that is treated as spam:
It seems to contain a couple of client domain names in the header info that i host for people any ideas why that would be the case? I use a shared IP address with about 10 domains on it
Received: (qmail 1436 invoked from network); 14 Aug 2009 16:02:10 +0100
Received: from clientdomain1.co.uk (HELO localhost) (91.192.***.196)
by clientdomain2.info with SMTP; 14 Aug 2009 16:02:10 +0100
Subject: Manchester 2 Day Seminar: Dealing with difficult people
From: events#domain.com
To: Andi <subscriber1#domain.com>
Date: Fri, 14 Aug 2009 15:02:10 +0000
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
"Roll your own mail" is often treated as spam by large hosted email systems. When you use a paid service to send out mass emails, you are paying for those company's agreements with the major email vendors to keep them white-listed.
One thing you can do, though, is to ensure that the account you are sending from exists and the email is being sent from a matching domain (e.g. #foo.com sent from foo.com's smtp server). That is a big red flag for spam filters.
Compare your email and email from outlook. Are any headers missing? Which? Do they seem significant?
Try this to get rid of the last localhost reference:
$protocol = new Zend_Mail_Protocol_Smtp('localhost');
$protocol->connect();
$protocol->helo('mail.yourserver.com'); //**DO THIS**
$transport->setConnection($protocol);