I need to be able to make a program that looks through a mailbox of bounced messages, where the messages come back with the initial message in a .msg attachment, and open the .msg attachment for processing in ASP.NET 2.0. Is there any sort of code that might help in this? I've been looking at Reading Email using Pop3 in C# as a starting point, but can't figure out how best to open the attachment from there, or if there's some easier way I'm missing.
From your post, it appears that you are better off getting a third party component that had already implemented (POP or IMAP) the protocol.
I just googled and got one and I bet there are a bunch out there.
http://www.jscape.com/articles/retrieving_email_pop3_csharp.html
Parsing bounce messages in general is a huge task, because their formats vary greatly between different mail transport agents. So unless you are on a closed network, or you only care for bounces reported directly from your own transport agent, then you are in for a big job, and you certainly cannot count on the original messages being attached in full to the bounce answers.
If it is possible for you to regenerate the outgoing mails from a few key parameters, then you might want to consider using a VERP addressing scheme instead. Your parsing job would then be reduced to recognizing and deciphering the recipient addresses of the bounce messages, instead of their full content.
I ended up going with a solution involving reading in the messages using Microsoft.Office.Interop.Outlook ( http://support.microsoft.com/?kbid=310244 ), saving the attached .msg to the drive, then finally reading in that message using an open-source third party solution ( http://www.codeproject.com/KB/office/reading_an_outlook_msg.aspx ). It's probably not the most efficient solution overall, but it handles the specific case we needed to support.
Related
I would like to implement an email receiving feature similar to the one found at asana.com:
http://asana.com/guide/tags-email/email-incoming
Users can send email to a designated address, and the system will perform actions based on recipient and message contents.
Any recommendations for libraries that handle this?
I see openpop.net, but i wonder if this technology would have a delay since by nature pop doesn't receive mail on its own, you must initiate the request.
Anyway, hoping to get the scoop on this technology from the experts here. Preferably, an answer would direct me to both a library and some tutorial/documentation.
If you're doing this on a Linux box, it's fairly straight-forward to set it up such that incoming emails are piped directly to a script - be it PHP, PERL, etc. See http://harrybailey.com/2009/02/send-or-pipe-an-email-to-a-php-script/ for an excellent article.
I am working on a program to parse ARF (Abure Reporting Format) messages. It turns out I need to be able to handle Hotmail feedback loop messages as well.
Does hotmail use ARF for its feedback loop message? If not, which format is it using?
I found this site providing a perl parser to convert hotmail messages to ARF format which make me think it is not using it.
I read somewhere it was using JMR (Junk Mail Reporting) but I can't found any example of such a message on the Internet.
Microsoft, as usual, has come up with their own proprietary alternative to the standard (at least they're consistent, I guess) called JMR - Junk Mail Reporting.
No, unlike e.g. AOL Hotmail doesn't use the ARF. Instead you'll get emails with the subject "complaint about message from [ip]* from "staff#hotmail.com", which contain the original body.
What is the best way to figure out which email users can be removed from their bounce mail message?
Example being a bounce mail error code of 5.1.1, where the mailbox no longer exists.
I'm using the mbox file format from Thunderbird.
My ideas include searching for Status: 5.1.1 then looking ~2 lines down to see the X-Display-Name: example#online.de.
Does anyone know how to do this?
One way you handle bounces is the way the ezmlm bounce handler does it. It sends a series of bounce messages to the address that bounced to test whether the bounce was temporary or permanent. They describe their technique in a fair bit of detail on their Bounces and Automated Bounce Handling help page.
There is Jason Rowe's excellent blog post on Sending Email and Bounce Handling Rules.
Also check out these Bounce Handling Best Practices.
Or you can manually code which messages you want to bounce based on the bounce mail code. You can get the list of all codes in RFC 3463 which explains what each one means and what type of failure they are.
Deciding what is a hard or soft bounce isn't a science. It's an art. I've researched and thought of programming this myself, but found it was opening a can of worms. Then I was going to use phpList and figure out how its bounce handler worked. That was no easier.
What I ended up doing was taking the easy way out and using LuxSci for my bulk emailing and simply using their Bounce Analysis to inform me which emails are "permanent delivery failures" of any kind.
Sadly, there is not a standard way to catch all bounced messages. For a pile of existing messages, you'll have to analyze the pile and try to extract the most common formats. You could probably handle the majority of the bounced detecting with a moderate number of pattern-match schemes.
we've got different processes that send mails in case of issues encountered (e.g. not enough permissions to perform an operation on a certain order item). This works fine to the point that sometimes identical messages are sent every 5 minutes. In our environment it is very difficult to synchronize the email sending on application layer (actually there are different applications sending out email, so we'd have to touch every application if we were to implement this inside application layer).
It would seem logical for me that filtering out mails (by duplicate subjects) is best done within the email layer, e.g. the application receiving the SMTP requests.
Yet we'd also prefer not to go down to SMTP layer by ourselves, rather use an existing service/application.
Is anybody aware of a web mailer (like googlemail) which does this kind of filtering? it would be ok for us the pay for such a service, so being "free as in beer" would be nice, but being not free is not a showstopper.
Thanks in advance
Holger
I find the idea of filtering duplicate e-mail message by the Subject: header quite worrisome. If they are produced by multiple applications, how can you be certain that the content of the messages is duplicated and that you are not unwittingly dropping important notifications?
The only unique feature of a message that can be used to filter out duplicates is its Message-ID: header. If that header is the same for two messages, then it's usually reasonable to assume that they are copies of the same original message - e.g. one received directly and one that was CC'ed to a mailing list.
That said, you can do pretty much anything you want on most SMTP servers - at least those that are based on a Unix-like OS. For example, Postfix can use custom shell scripts for filtering.
You can, for example, use formail to extract the body of each message and produce its
MD5 hash. Comparing the message body hashes along with the Date:, Subject:, From:, To: and Cc: headers at the same time is a good start to detect real duplicates.
My university refused to allow us to access out mail via POP or IMAP etc so I want to write a GTK based C app that sits in my notifcation area and does the job of a mail client notifier. Because I can't use anything like POP or IMAP, what would be a good way to do it? I guess I could scrape the HTML and look for a tag that is only present in unread mail or something?
Any Ideas?
I know you said C/GTK but it's a piece of cake in Python/GTK with urllib2, libcookie, and BeautifulSoup. That way you don't have to deal with raw sockets, and parsing the HTML yourself. Hell if you edit your question with a link to the source I could hack this up for you in no time. But if you're doing this as a socket exercise, more power to you :P
You should note that most server admins don't take too kindly too frequent scraping of their site, and you should probably clear it with them, lest you face the repercussions.
Well yes, if the only way to access your email is through webmail then any tool you create will have to use the webmail markup to work out new messages.
Personally I'd try and find out why POP/IMAP isn't allowed. As far as I'm concerned that's a really strange policy.
In precedent job, the only access we had to email was through a webmail (squirrelmail) at the time, I had wrote a Perl script with WWW::Mechanize that went through the pages to fetch the emails, send them via smtp to an external mailbox, delete them, and expunge the trash...
It's was about 20/25 lines of code. Off course, a C version would be a bit bigger because it would not have WWW::Mechanize :-)