In messages I send with Thunderbird I have the following email header
Content-Type: multipart/alternative;
boundary="000_160551222008756181axiscom"
All the history is divided by lines looking like
--000_160551222008756181axiscom
Those initial -- mess things up for other mail viewers like Outlook's webmail client. Where does those -- come from, and how do I get rid of them?
I'm using version 78.4.2 (64-bit) of Thunderbird.
The hyphens come from RFC2046. You don't normally get rid of them. Look for the problem elsewhere.
The Content-Type field for multipart entities requires one parameter,
"boundary". The boundary delimiter line is then defined as a line
consisting entirely of two hyphen characters ("-", decimal value 45)
followed by the boundary parameter value from the Content-Type header
field, optional linear whitespace, and a terminating CRLF.
Related
I have a mail command that looks something like this:
sh ~/filter.sh ~/build/site_build.err | mail -s "Site updated." me\#site.com
The bash script has a few commands, mostly grep, to filter the stderr. It sends the filtered content to me when our build process has finished.
It used to send the file contents in the message body, however now it's sending as an attachment, which I do not want.
When I delete most of the text it sends to me in the message body once again, so I've reasoned that this has to do with the message size -- is this correct?
Anyway, how can I prevent Unix from sending the message contents as an attachment, no matter the circumstances?
Thanks!
Still unsure as many things could cause mail to apparently send input as attachement. But in many Linux distribution, mail is an alias for is heirloom mailx. It is known to encode its input if there are any non printable characters in it.
As soon as it finds non standards characters, it adds the following headers to the mail :
Content-Type: application/octet-stream
Content-Transfert-Encoding: base64
and the text of the mail is effectively base 64 encoded. It is not a true attachement, but many mail readers treat such mails as an empty body with an unnamed attached file.
If your LANG environment variable declares a locale that can use non 7 bits chars (éèûôüö ...) mail seems to be clever enough to declare an extended charset (ISO-8859-1 for fr locale) and to do quoted-printable encoding. So even with (at least west european) non 7bits ASCII characters in the message, provided there are no control chararacters, the mail should be sent normally.
The alternative would be to filter all non printable characters from the output of filter.sh, and the last chance solution would be not to use mail and directly use sendmail.
(Ref : an answer of mine to an other post but that one concerned java)
I have a similar problem to this question, but could not find any useful information in the answers.
I'm trying to send an email to a recipient with a display name Lastname, firstname using the Quoted-Printable encoding. The exact header, as seen in the source of the received email, is:
To: =?UTF-8?Q?"Lastname,=20firstname"?= <email#example.com>
However, Outlook displays it like this:
Effectively interpreting the comma as a separator between recipients, even though it's enclosed in a Quoted-Printable encoding.
When there is no comma, the header is properly interpreted.
Am I doing something wrong, or is it impossible to use commas in a display-name?
Note: I'm currently using Amazon SES and the ZF2 Zend\Mail component, but the tools should not matter, I'm only interested in the correct header format and will adjust my tools or code accordingly.
What you are seeing is not correct behavior as far as I can tell, but the workaround should be obvious: QP-encode the comma. The double quotes are redundant and should be omitted:
From: =?UTF-8?q?Lastname=2C_Firstname?= <email#example.com>
(As such, it is obviously insane to put the last name first; but e.g. Outlook connected to Active Directory seems to insist on this silly anti-convention.)
Alright. I thought this problem had something to do with my rails app, but it seems to have to do with the deeper workings of email attachments.
I have to send out a csv file from my rails app to a warehouse that fulfills orders places in my store. The warehouse has a format for the CSV, and ironically the header line of the CSV file is super long (1000+ characters).
I was getting a line break in the header line of the csv file when I received the test emails and couldn't figure out what put it there. However, some googling has finally showed the reason: attached files have a line character limit of 1000. Why? I don't know. It seems ridiculous, but I still have to send this csv file somehow.
I tried manually setting the MIME type of the attachment to text/csv, but that was no help. Does anybody know how to solve this problem?
Some relevant google results : http://www.google.com/search?client=safari&rls=en&q=csv+wrapped+990&ie=UTF-8&oe=UTF-8
update
I've tried encoding the attachment in base64 like so:
attachments['205.csv'] = {:data=> ActiveSupport::Base64.encode64(#string), :encoding => 'base64', :mime_type => 'text/csv'}
That doesn't seem to have made a difference. I'm receiving the email with a me.com account via Sparrow for Mac. I'll try using gmail's web interface.
This seems to be because the SendGrid mail server is modifying the attachment content. If you send an attachment with a plain text storage mime type (e.g text/csv) it will wrap the content every 990 characters, as you observed. I think this is related to RFC 2045/821:
Content-Transfer-Encoding Header Field
Many media types which could be usefully transported via email are
represented, in their "natural" format, as 8bit character or binary
data. Such data cannot be transmitted over some transfer protocols.
For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
data with lines no longer than 1000 characters including any trailing
CRLF line separator.
It is necessary, therefore, to define a standard mechanism for
encoding such data into a 7bit short line format. Proper labelling
of unencoded material in less restrictive formats for direct use over
less restrictive transports is also desireable. This document
specifies that such encodings will be indicated by a new "Content-
Transfer-Encoding" header field. This field has not been defined by
any previous standard.
If you send the attachment using base64 encoding instead of the default 7-bit the attachment remains unchanged (no added line breaks):
attachments['file.csv']= { :data=> ActiveSupport::Base64.encode64(#string), :encoding => 'base64' }
Could you have newlines in your data that would cause this? Check and see if
csv_for_orders(orders).lines.count == orders.count
If so, a quick/hackish fix might be changing where you call values_for_line_item(item) to values_for_line_item(item).map{|c| c.gsub(/(\r|\n)/, '')} (same for the other line_item calls).
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'm looking at the source of a multi-part message from Thunderbird (in hopes of writing my own multi-part message from C++/Javascript)
I was wondering what the follow means (the part between the text-only part and the html part of the email) and how I might calculate it for my own program to generate a multi-part email:
This is a multi-part message in MIME format.
------=_NextPart_32252.1057009685.31.001
Content-Type: multipart/alternative;
boundary="----=_NextPart_32252.1057009685.31.002"
Content-Description: Message in alternative text and HTML forms
------=_NextPart_32252.1057009685.31.002
(as seen here)
The rest of the message code makes sense to me for the post part.
The numbers you are seeing within the boundary delimiters don't necessarily mean anything (although the RFC doesn't preclude an implementor from trying to include some meaning).
They must be unique and not contained within the part that they encapsulate.
From RFC 2046:
5.1. Multipart Media Type
In the case of multipart entities,
in which one or more different sets
of data are combined in a single body,
a "multipart" media type field must
appear in the entity's header. The
body must then contain one or more
body parts, each preceded by a
boundary delimiter line...
As stated previously, each body part is preceded by a boundary
delimiter line that contains the boundary delimiter. The boundary
delimiter MUST NOT appear inside any of the encapsulated parts, on a
line by itself or as the prefix of any line...
...
5.1.1. Common Syntax
The Content-Type field for
multipart entities requires one
parameter, "boundary". The boundary
delimiter line is then defined as a
line consisting entirely of two
hyphen characters ("-", decimal value
45) followed by the boundary
parameter value from the Content-Type
header field, optional linear
whitespace, and a terminating CRLF.
...
NOTE: Because boundary delimiters must not appear in the body parts
being encapsulated, a user agent must exercise care to choose a
unique boundary parameter value. The boundary parameter value
[could be] the result of an algorithm designed to
produce boundary delimiters with a very low probability of already
existing in the data to be encapsulated without having to prescan the
data. ... The
simplest boundary delimiter line possible is something like "---",
with a closing boundary delimiter line of "-----".
They don't mean anything. They are just a random string that does not occur within the body of the email. They are just used to mark where the embedded message starts and stops.