[
https://issues.apache.org/jira/browse/NIFI-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381120#comment-15381120
]
Andre commented on NIFI-1899:
-----------------------------
[~joewitt], [~djmdata]
So that everyone is familiar with my twisted way of thinking behind this PR: :-)
The rationale behind 3 processors was that {{ListenSMTP}} was to be used as an
OS independent SMTP interface where adequate, reducing the footprint of the
underlying OS, without losing the SMTP ingestion capability.
Where other SMTP funcionality is required (e.g. RBLs) and greater latency
acceptable, the DFM may chose to use the OS provided MTA (e.g. _postfix_)
configured to save messages to individual files (in postfix lingo this is
called maildir-style mailbox) and use {{ListFiles}} + {{GetFiles}} to ingest
the RFC-822 messages into NiFi so that it may follow its journey through the
flow.
Or perhaps, the DFM could simple chose to ingest using the upcoming _POP3, IMAP
and Exchange_ "getters" implemented by [~ozhurakousky] as part of
NIFI-1148.(Although I'm not sure yet if Oleg will chose to adopt a similar no
Headers parsing approach).
Another point that should also not be ignored is that the current modular
approach also allows the use of non-SMTP listeners as input channels to email
data. At Fluenda we are playing with the idea to copy SMTP messages into NiFi
using HTTP connection established by a small script called by the MTA as it
processes the incoming messages (This works very well with situations where
filtering is in place).
This is also the reason behind why {{ListenSMTP}} refrains from processing the
Headers presented in DATA as attributes, focusing instead in just recording the
the Envelope details provided by {{SubEthaSMTP}}. (and to be honest as far as I
recall, MTAs should not process Header data, just envelopes).
*Regarding Message Size:*
To be absolutely honest I would not play with the idea of tying the Maximum
size with the downstream size of anything as this would introduce logic that
could be well addressed downstream. I may be the only one, but I see NiFi flow
as the best place to introduce deployment specific logic, preferring to leave
the standard processors as independent as possible.
In the case of [~djmdata] use case, I suspect one could possibly use
{{SplitText}} to achieve a similar result?
> Create ListenSMTP & ExtractEmailAttachment processors
> -----------------------------------------------------
>
> Key: NIFI-1899
> URL: https://issues.apache.org/jira/browse/NIFI-1899
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Andre
> Fix For: 1.0.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
