I'm trying to write application that periodically receives e-mails. It writes every mail into database. But sometimes i'm getting 'Re:' e-mail that looks something like this:
New message
On September 21, 2010 24:26 Someone wrote (a):
| Old message
|
The format depends on e-mail provider.
Is there any library that helps removing 'Re' part from e-mail message? Maybe IMAP server can do that? I have all the previous e-mails from thread in database so I can take them and search in new message.
If you are able to associate a reply (RE:) message with the original/previous message that it is a reply to, then I would think that you could grab the body text of the original/previous message from your database, and then remove that text from the body of the reply. However, this method will not be 100% accurate, because clients could convert an HTML/Rich Text email in to plain text, or vice-versa. In any such case, this method probably wouldn't work. Even so, this technique would be generic and probably work the majority of the time.
In addition, the email provider may add certain header fields, or preambles, to the beginnings of a quoted message in a reply. In this case, I don't think there is any "catch all" solution.
My recommendation would be to target a few of the really huge web-mail providers (Gmail, Yahoo, Microsoft, etc), learn the formats that they use for their replies and parse the messages accordingly. In addition, you could likely handle a few generic formats as well. For instance, the '>' character is commonly used at the beginning of each line of quoted text in a reply.
If you're going to be developing in a language like C#, create yourself an Interface like IReplyFormat, with a corresponding implementation for each provider, and possibly some generic formats.
I don't think you will find any catch-all/perfect solution to this problem, as there are simply too many mail providers with too many different formats. However, I think you can at the very least find some techniques, like the ones mentioned above, that will work for you more times than not, which is the best you can hope for at this point.
Personally I think that you are out of luck here, as the message copy is part of the body. So in order to remove it you will have to process the message's body and write an extraction method for each known format (obviously the problem is that you cannot know all possible formats).
So, instead of parsing the body why don't you persist the whole message into the database? Normally the size of the message should not be the problem with modern DBMS. If it really is a problem you always can compress the body and store it in a BLOB.
No IMAP Server will not and does not remove anything
Such library does not exist because there is no standard, every email provider does it differently, gmail etc have developped their own tools
You have to look for pattern, that will somehow begin with headers with recipient as sender, like...
From: <receipent>
From: "NAME" <receipent>
From: receipent
and you have to omit the parts from this line below, howerver only checking this will not be sufficient as usually from is followed by subject,cc,to etc, so the pattern needs to be checked. I think some open source project or text library may exist, but its too difficult to find it on google.
I agree with Obalix. It's too hard to filter out replies so must keep the whole message. However, when you present email to the user, you can hide some parts of it. Those part can be shown with an optional "Click here to see the full message" or similar. For instance, regular expression to filter '>' characters would look something like #"^[ \f\t\v>]*"
Related
I have written a custom pipeline component assembler to modify the response ACK HL7 message.
I have invoked Assemble(pContext) of Microsoft.Solutions.BTAHL7.Pipelines.HL72fAsm in the implemented method Assemble(pContext) of IAssemblerComponent interface
gives me result IBaseMessage
which is an HL7, then I do my manipulations on it to fix one of the fields and return that modified IBaseMessage.
All these works just fine, I tried EvenLogger to verify it.
But still the Sender application doesn't receive the modified message, it receives the auto-generated message.
Is there something I'm missing out, why do I not get the custom assembler result out from the SendPipeline of 2 way receive port
Note : BTAHL7 Configuration explorer is configured for original mode. The send pipeline on RequestResponse receive port is set to my custom pipeline
My suggestion is after all the more important points.
The first thing you're employer or customer should say is NO. That is invalid HL7 and you cannot support that.
But, if they are unable to unwilling to comply, the next thing you need to do is inform your management that their non-compliance will cost you a lot of extra time and money to accommodate. To fully support this change will likely cost more then implementing the business messages, I am totally serious. This is not a problem with BizTalk Server, you app or you.
Depending on the relationship, your management can legitimately ask them how they are going to pay for this customization. It's going to cost your side a lot more to break HL7 to comply with them than it will for them to fix it.
Next, and perhaps most important, due to the nature of it's message content, HL7 has very strict completeness requirements, which they are fundamentally breaking. The Trading Partner needs to fully document this requirement to take ownership of it because there is a huge consequence, they are breaking tracing/tracking on you end.
This means that it will be substantially more difficult to investigate and resolve messaging issues for you, not them. This might raise legal or compliance issues your side needs to be aware of.
So, provided you technical, medical and legal teams are all satisfied, the first thing I would try is a Pipeline Component that simply swaps the two values, MSH10 and MSA02. That way, they will receive both values.
Finally, here's a novel solution. Since this is their problem, and a problem for every one of their trading partners, what if you offer help them fix it. All then need to do is what I suggested, swap MSH10 and MSA02 on the received message.
I am wondering how should I set up interprocess unified communication in better way than I do now. Client process sends a lot of messages of different sort to the server process. Messages like... I have done some work[what],I started at [time], ended at[time]. or state, progress even command messages.
example message: From:Process1;StartedAt|12:12:12;EndedAt|12:45:56;DoneUnit:51
Server parser split string by semicolon. From first part reads from who was message sent. from second and third part it reads times and from last how much work it did.
When I add another info at the end of message
ex. From:Process1;StartedAt|12:12:12;EndedAt|12:45:56;DoneUnit:51;Source:tableT
I have to rewrite the server parser as well.
Server tries to parse received message using my own parse function. Every message has its own format. So parser know how should message look. But if I change the format on client I have to change it on server as well. It does not seems to be very efficient way.
For that reason I ask you a question.
How should this communication get better or is there any different approach how to store the format for client and server on one place?
I use c# .net 3.5(Must be this version)
Thank you for reply
The obvious solution to your problem would be to not write the parsing code yourself.
If you create a class that can be serialized, you can send the serialized version of the class over the wire and deserialize at the other end. That means the message class can be shared between both applications, and the parsing code is trivial. Depending on your requirements, you can use various serializers: Xml or JSON would be verbose but human-readable, or the binary serializer would be more efficient in terms of bandwidth (but harder to debug or monitor over-the-wire).
I want to create my own email template without having to use third party software,I would just like to clear up some basics for my self :)
Firstly, do all email templates come down to pretty much being HTML body with inline CSS? Thus sending a templated email with C# would go somthing like:
SmtpClient smtpClient = new SmtpClient("smtphost");
MailMessage msg = new MailMessage();
msg.To.Add("toaddress6#place.com");
msg.Subject = "A TEMPLATE";
msg.Body = "<body> This is where the html goes O.o </body>";
msg.From = new MailAddress("fromaddress#anotherplace.com");
msg.IsBodyHtml = true;
smtpClient.Send(msg);
Secondly, sending images with a template I'm assuming they are either added on as an attachment or are linked to via a long address to the image location on the server, similar to a webpage? and displayed in the html.
I haven't tried it before, but take a look at the MailDefinition class.
Here's some solutions I have ran into while creating email templating systems:
There's no built-in templating system built into the framework that I know of. I built a system that worked pretty well in the past. Nowadays I do things simply. I would replace items like {year} with the current year, {year2} for a 2-digit year OR {year:2,} which is more work, but results in any of your variables to have the ability to do an inline SubString() without much work past the initial build. (you could do {var:name:upper}, :lower, :titlecase; you can pass in an object and use simple reflection techniques to read all the public properties and do automatic replacements... the sky is the limit!) The important thing is to give yourself a lot of leeway without violating the YAGNI principle too much. When you're building a system like this...
Start with examples of how you want to end up. I ended up writing something like <html><body><h1><font face="arial">Hello, <b>{var:firstname}!</b> It's {hour} {ampm} here...</font></h1> ...</html> which would do the replacements and spit out the final copy. Then, check using a regex that everything was replaced so you're not sending out Hi, null null! It's nice to see you at {hour} {ampm}! and make you the laughing stock of your recipients. Think hard about how you want to be able to insert content. You can do lots of crazy things with your own templating system, good and bad, so TEST TEST TEST. Unit tests are handy for regression testing. Remember, once you go live, you don't want to make mistakes since you're sending them to the customer and there's no way of changing it before the client sees it like you can do with a web site.
Most HTML newsletters are in HTML format, use inline-CSS or (gasp!) TABLEs and FONT tags for layout. The reason behind this is because most email HTML rendering engines are stuck in the past. What works with Thunderbird may work somewhat well with Mozilla, but will look like garbage in GMail or Hotmail. My recommendation is to use as little inline CSS as possible, and if you do, test with a few email clients, including web- and non-web-based clients to make sure you get the desired effect in each one. Use TABLEs for layout, no fancy CSS3 stuff. The KISS rule applies here, and yes, it's a blast from the past using the old-style HTML. You may feel like you need to take a shower after writing that horrible code, using tables for layout, etc., but that's what we need to do with what we are given.
Read this too: http://www.hongkiat.com/blog/design-perfect-newsletter/
I want to add global exception handling code to C# WPF apps and, although it seems rather rakish (nobody else seems to do it), I want to send email to the developer with exception info. The main problem I can think of happening here is if the developer ends up changing his email address after the software has been deployed. Perhaps an email to the department (such as a listserv type of email broadcast address) would be more appropriate? Has anybody used this sort of methodology, and if so, what solution have you come up with to make sure that somebody gets the exception-generated email?
Is this the best solution:
// in exception code (pseudocode)
try
SendEmailToTheCoder();
catch
on EmailAddressNotValid:
try
SendEmailToTheListServ()
catch
on EmailNotSent:
LogExceptionDataToLog("Bla");
...or has my brain gone pear-shaped again (I don't know what that means, but it's British, so it must be wickedly funny)
The best thing to do is to keep the details of the messaging outside of the application.
For instance, you may log errors to a text file or some other kind of log, then have an external application or Windows service monitor that log and decide what to do -- such as sending an email, or creating a digest of all messages of the day and emailing it, or a similar action.
This way, you can optimize and modify what happens in case of these errors, without having to change your program code. You can also reuse that system with other applications that also just log errors to a text file, which has a lower probability of error than connecting to an SMTP server and sending a message.
I would just create a distribution group, something like developer#yourcompany.com and add people responsible for the program part of that distribution group. If one developer leaves the company, nothing in your code needs to change and no trying one thing first and then another one.
Better yet, use a logging framework such as log4net (nlog is also popular); you can configure it to log to different places (xml, database, email, etc). If you do log to email, I'd always send it to a distribution group, anyway, even if that distribution group is composed of only one member.
I am about to write a simple email manager for the site I'm working on (asp.net/c#); the site sends out various emails, like on account creation, news, some user actions, etc. So there will be some email templates with placeholders like [$FirstName] which will be replaced by actual values. Pretty standard stuff. I'm just wondering if someone can advise on existing code - again, i need something very simple, without many bells/whistles, and obviously with source code (and free)
Any ideas/comments will be highly appreciated!
Thanks,
Andrey
There are several threads on Stack Overflow about this already, but I ended up rolling my own solution from various suggestions there.
I used this FormatWith extension method to take care of simple templating, and then I made a basic Email base class to take care of common tasks, like pulling in an appropriate template and replacing all the requisite info, as well as providing a Send() method.
All the emails I need to send have their own subclass deriving from the base, and define things unique to them, such as TemplateText, BindingData, Recipients, and Subject. Having them each in their own class makes them very easy to unit test idependently of the rest of the app.
So that your app can work with these email classes without really caring which one it's using, it's also a good idea to implement an interface, with any shared methods (the only one I cared about was Send()), so then your app can instantiate whatever email class it wants and work with them in the same way. Maybe generics could be used, too, but this was what I came up with.
IEmail email = new MyEmailClass();
email.Send();
Edit: There are many more suggestions here: Can I set up HTML/Email Templates with ASP.NET?
I always do the following. Templates = text string with {#} placeholders. To use a template I load the string (from whatever store) and then call string.Format(template,param1,param2..)
Simple and works well. When you need something stronger you can move to a framework of some kind but string.format has always worked well for me.
note
Alison R's link takes this method to the next step using 3.5's anonymous types to great effect. If you are 3.5 I recommend using the FormatWith there (I will) otherwise this way works well.
Having just done this myself, there is some great information at: Sending Email Both in HTML and Plain Text. Best part is, you don't need anything other than .NET.
Essentially, you create an HTML page (AKA, your formatted e-mail) with the tags that you want to replace (in the case of this solution, tags will be in the format of: <%TAGNAME%>). You then utilize the information found at the above website to create a mail template with the tags filled with the appropriate data, and the injections will be done for you into your HTML template. Then, you just use the SMTP classes built into .NET and send the mail on its way. It's very simple and straightforward.
Let me know if you have any additional questions. Hope that helps!
If you are using ASP.NET, you already have a templating engine available to you. Simply create an ASP.NET page that will produce the results for you (using whatever controls, etc, etc) you want, as well as setting the ContentType of the response to the appropriate type (either text or HTML, depending on the email format)
Make sure that this url is not publically exposed.
Then, in your code, you would create an HttpWebRequest/HttpWebResponse or WebClient and then fetch the URL and get the contents. The ASP.NET engine will process the request and return your formatted results, which you can then email.
If you want something simpler, why not use a RegEx and match? Just make sure you have a fairly unique identifer for your fields (prefix and suffix, which you can guarantee will never be used, or, you can at least write an escape sequence for it) and you could easily use the Match method to do the replace.
The only "gotcha" to the RegEx approach is that if you have to do embedded templating, then that's going to require a little more work.