[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762481#comment-16762481
]
Michael Bailly commented on JAMES-2658:
---------------------------------------
Hi Matthieu,
Thank you to have taken time to read & comment my proposal. Here are my 2 cents
:
> retries
ok
> async
If the mailet pipeline has to be sequential, the async behaviour can't ofc be
implemented. The good thing about being able to async process would be to not
degrade performances, which is a point you raised later on. So the more simple
answer may be to remove the "async" part of this proposal. Enabling async
processing in the mailet pipeline may offer more capabilities, I understand it
can be a complex topic.
> about service return value
You read my mind here. I got tons of ideas around, and that's why I did not
name the mailet "addHeaders" but gave it a more generic name. So yes,
"replaceHeaders", "removeHeaders", "setHeaders" and other actions looks
promising, but I have to start somewhere.
> emailFolder
Agree. So that means this attribute MAY be set, depending on the placement of
the mailet in the processing pipeline. It's the responsability of the remote
webservice to support both cases.
> Email as JSON
We hit the hard point here (and also in your LMTP point). The thing is, email
RFC 2822 processing is a specific business, and asking remote webservices to
handle it may lead to a diversity of decoding (diversity of bugs). My opinion
is that email specific stuff is the job of the mail server. Having JMAP in
James means that the server is already able to provide RFC 2822 to JSON
conversion. Webservices focus, IMHO, should be on data processing and
manipulation, not RFC 2822 decoding. Also I suggest to use the JMAP JSON email
representation as a de-facto Email as JSON format.
> How often it gets call
For each email recipient
> Performance
Right. That's why I proposed async... I guess it's a "generic vs performance"
kind of trade off.
> LMTP
Hard point part 2. The thing is, almost everyone knows HTTP and webservices.
And, as you noted, not that much people knows LMTP. So it would be way easier
for developers to enhance emails by creating web services, because they know
HTTP and webservices. In the company I work on, which may or may not be
representative, I give you that, we already have two working webservices that
would add interesting data to an email (namely, smart replies and important
emails detection), and that we will be delighted to contribute in Open Source,
and the developers provided us with a ready to use webservice, not a LMTP
service, because they have no clue about LMTP.
> Generic mailet to call an external microservice, and add extra information to
> an email
> --------------------------------------------------------------------------------------
>
> Key: JAMES-2658
> URL: https://issues.apache.org/jira/browse/JAMES-2658
> Project: James Server
> Issue Type: Wish
> Reporter: Michael Bailly
> Priority: Minor
>
> Hello team. This is a Request For Comments for a feature, to be able to add
> extra information to an email on delivery to a local mailbox.
> h2. Principle
> the mailet calls a remote webservice, with a pre-specified payload. It gets
> back, either an error, or another specific payload. This payload can instruct
> the James server to add informations to the email. The first case, that we
> handle here, is to add extra headers.
>
> h2. Implementation
> OK, I'll try to map the mailet syntax, but I'll make mistakes, it's to
> illustrate the principle.
> James configuration:
> {{<mailet match="..." class="AddExtraInfos"
> endpoint="https://server.com/api/infos"; />}}
> Seeing this, the mailer issues a POST on {{[https://server.com/api/infos]}}
> with the following payload structure:
> {
> {{ "messageId" : "messageId",}}
> {{ "from" : {}}
> {{ "address" : "[email protected]",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "[email protected]",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "[email protected]",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "[email protected]",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "[email protected]",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +0000",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +0000",}}
> {{ "in-Reply-To" : "messageId_in_reply_to",}}
> {{ "subject" : "IMPORTANT: Testing The Priority Inbox",}}
> {{ "body" : "\nDear, \n\n this a test of the priority inbox\n
> regards,\nfirst_name last_name\nDirector Tester",}}
> {{ "attachments" : [{}}
> {{ "file_size" : "243534",}}
> {{ "content_name" : "presentation.pdf",}}
> {{ "content_type" : "APPLICATION/PDF"}}
> {{ }, {}}
> {{ "file_size": "243534",}}
> {{ "content_type" : "APPLICATION/PDF",}}
> {{ "content_name" : "performance.pdf"}}
> {{ }],}}
> {{ "emailFolder" : "INBOX",}}
> {{ "user" : "first_name last_name of to1",}}
> {{ "alternativeAddress" : [ "[email protected]",
> "[email protected]" ],}}
> {{ "X-Spam-Flag" : "NO"}}
> {{}}}
> Worth noting: all those attributes are JSON formatting of an email contents,
> EXCEPT:
> * emailFolder : the destination folder of the email
> * user & alternativeAddress : the user the email is delivered to
> This mailet expects a specific format for the response. Here is a proposal:
> 1/ "bypass" (do nothing)
> {{{}}}
> 2/ "add headers"
> {
> "addHeaders": [
> {name: "X-INFO1", value: "some header value"},
> \{name: "X-INFO1-SCORE", value: "0.4"}
> ]
> }
> h3. Handling failure
> The mailet may support a specific attribute to define the behaviour in case
> of failure.
> {{<mailet match="..." class="AddExtraInfos"
> endpoint="https://server.com/api/infos"; on-failure="ignore" />}}
> h3. Configuring retries
> The mailet may support a retry parameter, allowing to retry x times before
> "really" failing. The additional, optional retry delay parameter could set
> the time, in seconds, to wait between each retry.
> {{<mailet match="..." class="AddExtraInfos"
> endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" />}}
> h3. Setting blocking behaviour
> Some processing may not require an immediate response, and may allow further
> processing of the mailet chain. Here, either the "blocking" or the "async"
> attribute, I can't choose, may be used.
> {{<mailet match="..." class="AddExtraInfos"
> endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" blocking="false" />}}
> or, as a second proposal
> {{<mailet match="..." class="AddExtraInfos"
> endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" async="true" />}}
> h2. Things I don't know
> * Where to send email on failure, if the "on-failure" attribute is not
> "ignore".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
