After I started sending emails with Amazon SES, the "status" messages that my system sends don't look as nice as before.
Since then, the body of the email is crammed together on one line. Previously, the text was separated into nice little paragraphs for easy reading.
Example:
Hello, you have a status message from the zzz server today:
The server is not down.
Action required: Get a coffee
And now:
Hello, you have a status message from the zzz server today:The server is not down.Action required: Get a coffee
My system generates plain text for the body, using Visual Studio's Environment.Newline method to specify a new paragraph. (I believe this is equivalent to vbcrlf) Previously, using good old SMTPClient, that was generating email bodies the way I wanted.
How have I tried to get a solution?
One solution I have thought of would be to carefully encode each of these "status" messages in pure HTML. If necessary, I guess I will do that work, but it would involve a large amount of coding to ensure that all email bodies were pure html. I would rather find a simpler solution.
I see information on MimeKit.Text.Converter, and I am willing to invest time into using that, but this converter refers only to converting Flowed text, and I have had trouble discovering what that means.
If anyone can show me a simple way to convert a plain text email body into a basic html body, it would really make my day!
Related
When people email each other, they generally include the original email in their reply to a sender, adding a little more information each time to the email. Each email client seems to have a different way of adding the original email to a reply.
I need to parse email arriving at our mail server and try and extract the new part of the message, and I'm wondering if there is a sensible way to strip this appended (or prepended) information (the "original message") and just get the new information in a mail body? I believe sadly, that there is no encoding, the original email is simply added to the new message, but I thought I'd check with the experts?
thanks.
No, there is no simple, straightforward algorithm to separate quoted or forwarded text from new content. Quoting and forwarding are poorly standardized and different conventions have existed at different times.
Having said that, e.g. Google's Gmail succeeds fairly well in practice. With enough samples, you can clearly come up with reasonable heuristics.
Good indicators for quoted material are forwarded (pseudo-) headers and indented text, perhaps with a quote indicator along the left margin before the quoted text. You occasionally see outdents as well.
Traditionally, on Usenet in the early 1990s, people would use different, unique quoting styles.
: ~ | This seems to be the original.
: ~ This is the first reply.
: This is the second reply.
This is the third reply, quoting the
previous three messages in sequence.
Around 1995, both clients and standardization initiatives by and large converged on "wedge" quotes;
> >> This seems to be the original.
> > This is the first reply.
> This is the second reply.
This is the third reply, quoting the
previous three messages in sequence.
Then along came Microsoft and ruined it all. I suppose that top quoting makes sense in some corporate settings where you quickly need to collect all the background from a thread to a new participant, but even for that purpose it's a horrible abomination.
This is the third reply, quoting the
previous three messages in sequence.
---- Begin forwarded message ----
From: Him [smtp:bogus]
To: His Friend
Subject: VS: Re: Same as on this message
Date: nothing machine-readable
This is the second reply.
---- Alkuperäinen viesti ----
Lähettäjä: His Friend [smtp:poppycock]
Saaja: Some Guy
Aihe: Re: Same as on this message
Päivämäärä: olisiko eilen ehkä
This is the first reply.
----- Original message ----
From: Somebody Else [smtp:mindless]
To: Some Guy
Subject: Same as on this message
Date: like, the day before
This seems to be the original.
I have incoming email set up for SharePoint 2010, and am sending forms from InfoPath using that method, with SMTP server set up on the SharePoint Server machine. It seems easier than elevating the permissions of an anonymous user with the InfoPath code-behind option. I also tried a custom method of sending the emails but was unable to find a way to send the form data along with the email message using the InfoPath 2010 code-behind option. So, I found another way, using the advice from SharePoint UK's website.
My problem is that while removing the x-mailer header actually solved my problem regarding whole email messages, it did not allow the attached form data to be sent to the library. The message would be imported and then just disappear if I did not have the "Save original e-mail" setting enabled. Inspecting messages in the drop folder I found they had a content type of "multipart/related" and if I edited them with NotePad++ I could change that to "multipart/mixed" and the attached form data would then be imported as desired.
So I went about trying to modify the VB Script to make this happen BUT now nothing happens with the script at all. Clearly I'm doing something wrong with it and VBScript really isn't my area of expertise. Maybe it's just not possible to edit those fields or maybe I need to attack it from a different angle. How can I get my VBScript to edit the content type for these emails?
CODE:
Set shell = CreateObject("WScript.Shell")
shell.LogEvent 4, "starting mail filter"
if instr(iMsg.Fields("urn:schemas:mailheader:content-type"), "related") > 1 then
Dim logMsg = "Mail Type: " & iMsg.Fields("urn:schemas:mailheader:content-type")
Dim tempType = Replace(iMsg.Fields("urn:schemas:mailheader:content-type"), "related", "mixed")
shell.LogEvent 4, iMsg.Fields("urn:schemas:mailheader:content-type")
iMsg.Fields.Delete("urn:schemas:mailheader:content-type")
iMsg.Fields.Item("urn:schemas:mailheader:content-type") = tempType
iMsg.Fields.Update
shell.LogEvent 4, iMsg.Fields("urn:schemas:mailheader:content-type")
end if
shell.LogEvent 4, "end mail filter"
iMsg.DataSource.Save
EventStatus = 0
I looked into this in greater detail and found that the content-type property of an email message is one of the many that is read-only using this particular vbscript library. So, I would have to find some other way of editing the file, and the work involved is more than what it would take to find an alternate solution that skipped email altogether. Therefore, I am abandoning the plan of using email in this case. If you take something away from this, let it be that there are read-only properties for the mail message object in this script.
What I'm trying to do is format the email address like so Foo Bar <foo#bar.com> so email clients (including web based like gmail) will show the sender as "Foo Bar" and not just "foo" since that is the prefix on the email.
Is this possible in Magento 1.5? If I try to put the formatting in the field itself I get an error message.
That's what the Sender Name field does. This is what my setup looks like and what it looks like in Thunderbird (my webmail client formats it similarly, too):
You may look at code/core/Mage/Core/Model/Email.php for the actual mail implementation. You may notice it uses Zend_Mail. Now, here is the catch:
For security reasons, Zend_Mail filters all header fields to prevent header
injection with newline (\n) characters. Double quotation is changed to single
quotation and angle brackets to square brackets in the name of sender and recipients.
If the marks are in email address, the marks will be removed.
What you can do though is to make a module to rewrite the current class Mage_Core_Model_Email and overwrite the send() function. I covered rewriting classes before in this question's answer. Then, in this new rewritten class, you could PHPmailer, invoke shell mail commands, or whatever PHP library you would happen to know that would allow this behaviour.
Best of luck.
I'm not sure if it can work. In magento inside is a Zend_Validate which does validation of such email addresses. And I dont think so that email like 'Foo Bar ' is valid. But I think the display in customer's email client depend on client, no?
I have a raw email, (MIME multipart), and I want to display this on a website (e.g. in an iframe, with tabs for the HTML part and the plain text part, etc.). Are there any CPAN modules or Template::Toolkit plugins that I can use to help me achieve this?
At the moment, it's looking like I'll have to parse the message with Email::MIME, then iterate over all the parts, and write a handler for all the different mime types.
It's a long shot, but I'm wondering if anyone has done all this already? It's going to be a long and error prone process writing handlers if I attempt it myself.
Thanks for any help.
I actually just dealt with this problem just a few months ago. I added an email feature to the product I work for, both sending and receiving. The first part was sending reminders to users, but we didn't want to manage the bounce backs for our customer admins, we decided to have a message inbox that the admins could see bounces and replies without us, and the admins can deal with adjusting email addresses if they needed to.
Because of this, we accept all email that is sent to an inbox we watch. We use VERP to associate an email with a user, and store the entire email as is in the database. Then, when the admin requests to see the email, we have to parse the email.
My first attempt was very similar to an earlier answer. If one of the parts is html, show it. If it's text, show it. Otherwise, show the original, raw email. This broke down real fast with a few emails not generated by sendmail. Outlook, Exchange, and a few other email systems don't do that, they use multiparts to send the email. After a lot of digging and cussing, I discovered that the problem doesn't appear to be well documented. With the help of looking through MHonArc and reading the RFC's (RFC2045 and RFC2046), I settled on the solution below. I decided on not using MHonArc, since I couldn't easily resuse the parsing and display functionality. I wouldn't say this is perfect, but it's been good enough that we used it.
First, take the message and use Email::MIME to parse it. Then call a function called get_part with the array of parts Email::MIME gives you with ->parts().
get_part, for each part it was passed, decodes the content type, looks it up in a hash, and if it exists, call the function associated with that content type. If the decoder was able to give us something, put it on a result array.
The last piece of the puzzle is this decoder array. Basically, it defines the content types I can deal with:
text/html
text/plain
message/delivery-status, which is actually also plain text
multipart/mixed
multipart/related
multipart/alternative
The non-multipart sections I return as is. With mixed, related and alternative, I merely call get_parts on that MIME node and returns the results. Because alternative is special, it has some extra code after calling get_parts. It will only return html if it has an html part, or it will return only the text part of it has a text part. If it has neither, it won't return anything valid.
The advantage with the hash of valid content types is that I can easily add logic for more parts as needed. And by the time you get_parts is done, you should have an array of all content you care about.
One more item I should mention. As a part of this, we created a separate domain that actually serves these messages. The main domain that an admin works on will refuse to serve the message and redirect the browser to our user content domain. This second domain will only serve user content. This is to help the browser properly sandbox the content away from our main domain. See same origin policy (http://en.wikipedia.org/wiki/Same_origin_policy)
It doesn't sound like a difficult job to me:
use Email::MIME;
my $parsed = Email::MIME->new($message);
my #parts = $parsed->parts; # These will be Email::MIME objects, too.
print <<EOF;
<html><head><title>!</title></head><body>
EOF
for my $part (#parts) {
my $content_type = $parsed->content_type;
if ($content_type eq "text/plain") {
print "<pre>", $part->body (), "</pre>\n";
}
elsif ($content_type eq "text/html") {
print $part->body ();
}
# Handle some more cases here
}
print <<EOF;
</body></html>
EOF
Reuse existing complete software. The MHonArc mail-to-HTML converter has excellent MIME support.
I was wondering if anyone knew how the thread-index field in email headers work?
Here's a simple chain of emails thread indexes that I messaged myself with.
Email 1 Thread-Index: AcqvbpKt7QRrdlwaRBKmERImIT9IDg==
Email 2 Thread-Index: AcqvbpjOf+21hsPgR4qZeVu9O988Eg==
Email 3 Thread-Index: Acqvbp3C811djHLbQ9eTGDmyBL925w==
Email 4 Thread-Index: AcqvbqMuifoc5OztR7ei1BLNqFSVvw==
Email 5 Thread-Index: AcqvbqfdWWuz4UwLS7arQJX7/XeUvg==
I can't seem to say with certainty how I can link these emails together. Normally, I would use the in-reply-to field or references field, but I recently found that Blackberrys do NOT include these fields. The only include Thread-Index field.
They are base64 encoded Conversation Index values. No need to reverse engineer them as they are documented by Microsoft on e.g. http://msdn.microsoft.com/en-us/library/ms528174(v=exchg.10).aspx and more detailed on http://msdn.microsoft.com/en-us/library/ee202481(v=exchg.80).aspx
Seemingly the indexes in your example doesn't represent the same conversation, which probably means that the software that sent the mails wasn't able to link them together.
EDIT: Unfortunately I don't have enough reputation to add a comment, but adamo is right that it contains a timestamp - a somewhat esoteric encoded partial FILETIME. But it also contains a GUID, so it is pretty much guarenteed to be unique for that mail (of course the same mail can exist in multiple copies).
There's a good analysis of how exactly this non-standard "Thread-Index" header appears to be used, in this post and links therefrom, including this pdf (a paper presented at the CEAS 2006 conference) and this follow-up, which includes a comment on the issue from the evolution source code (which seems to reflect substantial reverse-engineering of this undocumented header).
Executive summary: essentially, the author eventually gives up on using this header and recommends and shows a different approach, which is also implemented in the c-client library, part of the UW IMAP Toolkit open source package (which is not for IMAP only -- don't let the name fool you, it also works for POP, NNTP, local mailboxes, &c).
I wouldn't be surprised if there are mail clients out there which would not be able to link Blackberry's mails to their threads. The Thread-Index header appears to be a Microsoft extension.
Either way, Novell Evolution implements this. Take a look at this short description of how they do it, or this piece of code that finds the thread parent of a given message.
I assume that, because the lengths of the Thread-Index headers in your example are all the same, these messages were all thread starts? Strange that they're only 22-bytes, though I suppose you could try applying the 5-bytes-per-message rule to them and see if it works for you.
If you are interested in parsing the Thread-Index in C# please take a look at this post
http://forum.rebex.net/questions/3841/how-to-interprete-thread-index-header
The snippet you will find there will let you parse the Thread-Index and retrieve the Thread GUID and message DateTime. There is a problem however, it does not work for all Thread-Indexes out there. Question is why do some Thread-Indexes generate invalid DateTime and what to do to support all of them???