On the issue of email parsing

[Li-fan Chen]

Hi,

We work with email in a large CRM solution and one of the email-related
tasks that has plagued us is our decision to make use of a 3rd-party
local-sourcer to work on the parsing of inbound email. It would appear
to be a simple exercise (writing a parser against a select few RFCs),
but having someone write this component NIH (doing it by hand, instead
of using a 3rd party component) has caused endless problems. We are
hoping to right this uncomfortably large sinkhole of time (we are
constantly finding badly parsed emails) by using an alternative.

I am not sure what would work. I understand that we are talking about a
parser that must parse out the components of emails:
Envelop and Message Header fields (From, To, Reply-to, etc),
Subject,
Message Body (possibly modern editions, such as HTML and Plain-Text
in a multipart/alternative),
Exposure of non-standard extension mail headers,
and Attachments...

_but the hard part_, I imagine, is that there are a multitude of
email readers/mailers,
mailing list engines,
standard-error-messages from mail servers,
and webmail ecosystems
--all aiming to meet the RFC wend sending out message--but not
necessarily having the budget/time/etc to produce the ideal compliant
output.

So where do I go to find a mature parser that has withstand the test of
time, having the benefit of an on-going paid team to update it towards
parsing-compliance quirky (but major) sources of email (within reason
ofcourse, sometimes the source of the offending email should fix the
bug). That we can use in=house, so that I can make use of the various
parts of the incoming email and present them to our users?

Your suggestions and insights in this matter are greatly appreciated,
thank you ahead of time for your help!!

Best regards,
-- Li-fan Chen