I'm searching for a method to convert msg files to eml format. I have Outlook 2010 but it appears only possible to save as msg. I did find some third party tools that can be used but I prefer not to use a third party tool - if possible.
If you are looking for a quick and dirty VB script, Redemption (I am its author) is probably your only option. Other options are IConverterSession (C++ or Delphi only) or explicitly building the MIME file one line at a time from various message properties (MailItem can be returned by calling Namespace.OpenSharedItem in the Outlook Object Model).
set Session = CreateObject("Redemption.RDOSession")
Session.Logon 'not needed if you don't need to convert EX addresses to SMTP
set Msg = Session.GetMessageFromMsgFile("c:\temp.test.msg")
Msg.SaveAs "c:\temp.test.eml", 1031
MSG file and EML file both formats are used for containing the email with the attachment, but different from each other. EML extension used by multiple email clients, other hand MSG file only used by Outlook email client. In your scenario, you need an effective way to convert multiple MSG files to EML format, by using Outlook email client you can easily convert MSG file to EML format by using save as option of Outlook email client, but this way cannot convert their attachment.
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)
This is the actual problem I was trying to solve at
Workaround Perl regexp limit?
but my question wasn't broad enough.
I use Alpine to read mail, but have several mailboxes that are 100s of
megabytes in size. Alpine handles them fairly well, but doing "search
all text" is slow, and even using "grep" on the mailboxes (files)
directly can be slow.
Most of this size is due to base64 attachments. I don't really need
base64 attachments in my mailbox, since I can't usefully search for
text in them.
I want to remove the base64-encoded attachments from my mailbox, store
them in separate files, and replace the attachment with "[attachment
is now at /usr/attachments/somefile]".
Note that I actually want to store the base64-encoding in
"somefile". I do NOT want to decode it first. Why? Base64-decoding
broken attachments loses information. In other words, base64-decoding
a broken attachment and then re-encoding it might yield a different
string.
I want the ability to reconstitute my mailbox as it was,
character-for-character, before I "decomposed" the attachments. This
is useful for sha1 checking and my overall paranoia.
In other words, I want to move the bulky and helpful base64-encoded
attachments out of my mailbox, but without losing a single character.
My seriously failed attempt is at GITHUB
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 looking for a way to take a standard mail message (RFC 822 et. al) in a text file (say, from a mail spool or maildir), format it nicely, and output a postscript or PDF file suitable for printing. I'd prefer not to reinvent the wheel in terms of developing a pleasing layout, and I'm not familiar with PostScript or any graphics libraries anyway.
Are there any ready-made libraries or tools that can produce output similar to what most mail clients send to a printer? I've tried a couple of Linux command-line tools (like mp), but the output isn't very attractive.
You can solve your problem in two ways:
First:
Pass e-mail in "HTML Tidy" component or the "HTML Beautifier .Net" for the formatting and cleanup, and then convert with the "PDF Metamorphosis .Net"(www.sautinsoft.net).
Your HTML -> filter, clean up, modify HTML -> convert -> Your PDF
Second way:
Immediately send a message to "PDF Metamorphosis" for the converting to pdf.
Your HTML -> convert -> Your PDF
For example:
SautinSoft.PdfMetamorphosis p = new SautinSoft.PdfMetamorphosis();
string inputFile = #"С:\email.html";
string outputFile = #"С:\email.pdf";
int result = p.HtmlToPdfConvertFile(inputFile, outputFile);
if (result == 0)
{
System.Console.WriteLine("Converted successfully!");
System.Diagnostics.Process.Start(outputFile);
}
In the example for Zend_Mail on http://framework.zend.com/manual/en/zend.mail.attachments.html they use ENCODING_8BIT but searching for what that might be sends me to http://msdn.microsoft.com/en-us/library/ms526992%28EXCHG.10%29.aspx were (and this sounds logical to me) it is explained that 8bit encoding does not make sense for emails.
Edit:
When I use this encoding for a mail with an attachment, I receive the mail with a corrupted attachment in my mail software (Thunderbird)
In which cases does it make sense to use ENCODING_8BIT?
As everybody said, ENCODING_8BIT represents the Content Transfer Encoding.
Basically, 8BITMIME is used for Internationalization. It's using a 8-bit character sets and therefore, allow you to send any character supported in the UTF8 charset.
In general, non-MIME mailers send 8-bit data but do not include any
MIME headers to mark the message as 8-bit data. MIME mailers should
cope with this without any problems. [source]
So basically there is not really a case where it makes sense to use ENCODING_8BIT over another encoding since emails in UTF8 are a standard today. Also, note that most of the MTAs (Message Transfer Agent, such as Postfix, etc.) automatically force the encoding to 8BITMIME (UTF-8).
Here is a good resource about the 8BITMIME encoding.
The 8BITMIME extension has two effects in practice:
The client will avoid Q-P conversion.
The client may add extra
information at the end of a MAIL request: a space followed by either
"BODY=7BIT" or "BODY=8BITMIME".
Zend_Mime::ENCODING_8BIT sets the Content-Transfer-Encoding.
The Content-Transfer-Encoding defines methods for representing binary data in ASCII text format.
The use of Zend_Mime::ENCODING_8BIT in the example is a Bug.
For sending Attachments you should always use Zend_Mime::ENCODING_BASE64
Not for email but for attachements. If you take a look on the RFC 2045 at page 7:
RFC2045
"Binary data" refers to data where any
sequence of octets whatsoever is
allowed.