If I have an IMAP FETCH,
12 UID FETCH 3 (BODY.PEEK[HEADER] BODY.PEEK[TEXT])
And I respond with a
* 3 FETCH (UID 3 BODY[HEADER] {322}
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 07 Aug 2015 16:36:44 -0400
From: myemail#email.email
To: myemail#email.email
Subject: subjecct
Message-ID: <eea78aff8bfdfgvdfgvdgcdg655d14a4a7#email.email>
X-Sender: myemail#email.email
User-Agent: Roundcube Webmail/0.9.5
BODY[TEXT] {14}
myemailstuff
)
All is CRLF, the 322 properly says the length of the first block, from the CRLF after that line containing 322, to the CRLF before the BODY[TEXT] {14} (take note of the space before BODY).
From there, I add a space, and then the BODY[TEXT] {14}, etc. This doesn't work. I can't even find the specs in RFC 3501 for a single one, yet alone two in a row. Does anyone know where the specifications are for this, specifically, or know it off the top of their head?
Also, if it matters, this error came directly from an iPhone, and the server is my own(the embedded one in Avuna).
A literal takes the place of a quoted string or atom, and should have delimiters on either side the same way. That is {322}\r\n[322 bytes] should be treated exactly as a quoted string, with a space before and a space or parenthesis after.
I do not see any obvious problem with your sample, however, you may want to consider putting an extra CRLF in your headers in your literal, which may make some MIME parsers happier.
Related
Should I prepend all lines with '> '? Is that sufficient? Will it be accepted and understood by all major email clients?
In this case will a original.replace(/\n/g, '\n> ') regex replacement do what I want with the message?
What about the HTML version of the email? Use a big <blockquote>? Just prepending a <blockquote> and appending a </blockquote> will suffice?
Should I, like Gmail and others, prepend a line saying something like "someone <address#example.com> wrote at some time:"?
Plain text and by that I mean: Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
just requires ">" to quote the previous message (1 per line).
HTML version - depends on the client you're rendering in.
I have a raw email with headers that look like this:
From xxxx#xxxx Fri Apr 25 22:46:08 2003
>From xxxx#mxxxx Wed Feb 19 20:06:07 2003
Envelope-to: yyyy#xxxx
...
Date: Wed, 19 Feb 2003 22:05:59 +0500
From: "Actual Author" <xxxx#xxxx>
I don't know how to interpret the first two lines, and the initial reading of RFC2822 has left me without a clue. They don't look like normal headers and manage to confuse Python 2.7 email parser (fine if I remove the > sign at the start of the second line). I have the same email body in Apple mail's cache, and it seems fine, so the input is clearly correct.
What's that header format? (From <email> <date>\r\n)
Why is the second one prefixed with > (greater sign)?
What you have is a mail in mbox format, where the first "From" line marks the start of the message. The second line (>From) seems to be caused by the escaping strategy of mbox known as From quoting - has this message been double-encoded as mbox?
I have an app that sends e-mails and for many months, it was working fine. I recently had problems with utf-8 encoded emails sent to iPhone Exchange account (i.e. not IMAP).
All the receiver had to see was a big bunch of meaningless characters like LS0tLS0tPV9QYXJ0XzE0N18[....].
Comparing my email headers with Gmail, I noticed that I had an extra Content-Transfer-Encoding associated with the Content-Type: multipart/alternative;.
My email would look like
Delivered-To: ...
Received: ...
...
MIME-Version: ...
Content-Type: multipart/alternative;
boundary="----=_boundary"
Content-Transfer-Encoding: Base64 # <= the extra setting
----=_boundary
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: Base64
YmVu0Cg==
----=_boundary
Content-type: text/html; charset=utf-8
Content-Transfer-Encoding: Base64
PGh0bWwgeG1sbnM6bz0iIj48aGVhZD48dGl0bGU+PC90aXRsZT48L2hlYWQ+PGJvZHk+YmVub2l0
PC9ib2R5PjwvaHRtbD4NCjx9IjAiIC8+Cg==
----=_boundary
If I remove the extra setting, my email is received and display properly.
My questions:
Is the Encoding setting basically needed with Content-Type: multipart/alternative;, even for specific cases ?
Is it safe to remove it and just keep using my app as I used to ?
Edit
I found on IETF:
Encoding considerations: Multipart content-types cannot have encodings.
But I also found on Wikipedia:
The content-transfer-encoding of a multipart type must always be
"7bit", "8bit" or "binary" to avoid the complications that would be
posed by multiple levels of decoding.
Isn't it contradictory ?
The statements from IETF and wikipedia aren't really contradictory. 7bit, 8bit, or binary aren't really content encodings in that they don't specify any transformation of the content. They simply state that the content hasn't been encoded. In the case of 7bit it also specifies that the content doesn't need to be encoded even if the message needs to be sent over a transport that isn't 8-bit clean.
Only the bottom-most layers of messages should have an actual Content-Transfer-Encoding such as base64 or quoted-printable. In the message that you quote from the outer portion certainly isn't base64 encoded, so stating that it is was not only violating the standard but also incorrect. That would certainly be expected to cause problems with display of that message.
In practice, each part of a multipart has its own encoding, and it doesn't make sense to declare one for the multipart container. I cannot make sense of the Wikipedia quote anyway; in any event, it is hardly authoritative.
I'm generating emails. They Show up fine for me in gmail and Outlook 2010. However, my client sees the = sign that gets added to the end of lines by the quoted-printable formatting. It also eats the character on the next line, but then displaying the equal sign.
Example:
line that en=
ds like this
shows up like
line that en=s like this
(Note: The EOL character in my emails is just LF. No CR.)
I'm confirming what outlook version my client is using, but I think it's 2007. The email headers from her appear to come through Exchange 6.5.
My emails are created in php using the HtmlMimeMail5 library. They are multipart emails, with the applicable section sent with:
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
It appears I could just make sure nothing in my email reaches the line wrap at 76 characters, but that seems like the wrong way to solve the problem. Should the EOL character be different? (In emails from the client, the EOL character is simply a LF) Any other ideas?
I do not know what the PHP library does, but in the end MIME mail must contain CR LF line endings. Obviously the client notices that = is not followed by a proper CR LF sequence, so it assumes that it is not a soft line break, but a character encoded in two hex digits, therefore it reads the next two bytes. It should notice that the next two bytes are not valid hex digits, so its behavior is wrong too, but we have to admit that at that point it does not have a chance to display something useful. They opted for the garbage in, garbage out approach.
I've written an SMTP client that sends e-mails with attachments. Everything's fine except that when an e-mail sent by my program is received by Outlook it displays two attachments - the file actually sent and a file with two characters CR and LF inside and this file has name ATT?????.txt.
I've done search - found a lot of matches like this for similar problems and checked everything I could. Even more - I compared two emails - sent by my program and sent by Opera and I can't deduce the difference. However what Opera sends is interpreted correctly, but what my program sends is not. What my program sends is interpreted by a set of other mail clients correctly, but not by Outlook.
I've telnet'et to the SMTP server, retrieved the two emails into a text file - one from my program, another from Opera, and compared them side-by-side. I didn't see any difference that could affect interpretation by an email client.
Here's a sample message (addresses substituted, file contents cropped, blank lines exactly as they appear in real messages, lines never exceed 80 characters):
To: user1#host.com, user2#host.com
Subject: subject
Content-Type: multipart/mixed; boundary="------------boundary"
MIME-Version: 1.0
--------------boundary
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
here goes the Base64 encoded text part - it may be localized, so
it's better to UTF8 it and do Base64
--------------boundary
Content-Disposition: attachment; filename="file.jpg"
Content-Type: application/octet-stream; name="file.jpg"
Content-Transfer-Encoding: base64
here goes the Base64 encoded file data
--------------boundary
I tried to play with linebreaks after the last boundary - tried none, one, two, three, but this doesn't improve the situation.
Is there a set of some weird limitations that a mail client must follow to produce messages that are interpreted by Outlook correctly?
The last boundary of a MIME part must be indicated by appending two dashes:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------boundary"
--------------boundary
...
--------------boundary
...
--------------boundary--
More reading here: RFC1341 / 7.2 The Multipart Content-Type