[jira] [Commented] (JAMES-2658) Generic mailet to call an external microservice, and add extra information to an email
[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764745#comment-16764745
]
Raphaël Ouazana commented on JAMES-2658:
> Headers are immutable for a given mail once delivered.
- Should we consider other kinds of meta-data cf
[https://tools.ietf.org/html/rfc5257] ?
- Delete then recreates the mail with the new headers ?
Yes, annotate could be fine. And even if headers are immutable, you have
alternatives: moving to (a) folder(s), adding flags, and yes why not
annotations.
> 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:
> {{ 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" : "f...@test.com",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "t...@test.com",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "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" : [ "t...@test.com",
> "first_name.last_n...@test.com" ],}}
> {{ "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.
> {{ 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.
> {{ 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.
> {{ endpoint="https://server.com/api/infos; on-failure="ignore" retry="5"
> retry-delay="0.5" blocking="false" />}}
> or, as a second proposal
> {{ 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)
[jira] [Commented] (JAMES-2658) Generic mailet to call an external microservice, and add extra information to an email
[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764735#comment-16764735
]
Matthieu Baechler commented on JAMES-2658:
--
Implementing RFC 5257 seems a good move, thank you for the suggestion and the
link.
> Also about the API format, getting this generic enough might be a real pain.
> I really wonder if implementing a specific component, matching a well-defined
> service API is not better in the end than pushing most of the email
> complexity to the client... > For the record, we chose the specific component
> + well-defined service API option when implementing *email classification
> prediction*. What did change?
I'm not sure to understand what you wrote. BTW, what did change since *email
classification prediction* is:
* we don't want to write a James component every time we have to link and
external service
* email classification prediction had a poor design that allowed to go forward
with an experiment, we never meant to keep the design as-is
And finally, I already wrote it, but transforming a MIME mail to a JSON format
removes less than 1% of the complexity, so the "pushing email complexity to the
client" doesn't convince me.
> 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:
> {{ 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" : "f...@test.com",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "t...@test.com",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "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" : [ "t...@test.com",
> "first_name.last_n...@test.com" ],}}
> {{ "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.
> {{ 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.
> {{ endpoint="https://server.com/api/infos; on-failure="ignore" retry="5"
> retry-delay="0.5" />}}
> h3. Setting blocking
