@djmdata please consider subscribing to the dev list by sending an email to [email protected]
The JIRA for this work is here https://issues.apache.org/jira/browse/NIFI-1899 Feel free to help drive the conversation on there. Might not be a 1.0 release thing but looks like some good effort going on so should be in a release soon. As you point out parsing mail in the wild is...wild. We can just iterate on it and improve it. If you're interested in helping with coding some of it up too please feel free to jump in there. If not that is totally fine as well. Just having good requirements/perspective is valuable. Thanks Joe On Sat, Jul 16, 2016 at 8:53 PM, djmdata <[email protected]> wrote: > What is the JIRA #? > > I have a production system that reads email from a custom SMTP listener and > places the SMTP payload into Kafka. A Storm topology reads messages from > Kafka and parses the emails (Java code using JavaMail API) into useful info > (subject, text, attachments, body, etc...). > > I'm looking at plugging NiFi into this to replace the custom SMTP listener. > If you had a processor that could act as a reliable (we can't lose emails) > and performant SMTP listener alternative we would use it. > > Your "email parser processor" is an interesting idea - but beware of the > mess you'll find in the wild with email. In our case, we try to parse > Exchange (full of non-standard wonders like "TNEF" attachments") as well as > email from virtually anywhere (GMail, Yahoo, Joe's email client...). If you > can crack that you'll be on to something. We have even more complexity in > that we read "Microsoft Journals" which wrap the standard SMTP layout in a > Microsoft layer (you'll see this at large Exchange shops doing this kind of > thing for use cases like compliance). > > > > -- > View this message in context: > http://apache-nifi-developer-list.39713.n7.nabble.com/ListenSMTP-processor-tp10510p12827.html > Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.
