[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762513#comment-16762513
]
Matthieu Baechler commented on JAMES-2658:
------------------------------------------
> async
We will tackle this in the future, async should definitely be the default. The
question is more "when" then "if".
> Email as Json
Well, I think that you missed 2 things here:
# Email complexity is not in the serialization format. BTW, there are a lot of
good MIME decoding libraries out there. Even if you can find a good JSON schema
to express an Email, you still have to understand the Email structure, and
that's the hard part.
# JMAP Json format is not a perfect solution. For example, it replaces
non-text payloads with a reference to a blob that you can query by HTTP. You
won't be able to scan attachments, extract semantic from them, etc.
My own opinion is that if you have a webservice that claims to take decision
based on an email content, parsing the raw email is probably the least of your
problems.
> LMTP
I understand very well that HTTP and Json is more widespread than LMTP but:
# I don't say we should use LMTP, I said we should try to understand how it
works, what people say about it, etc
# It's easy to provide a webservice that consumes a public API (here the
public API would be JSON schema) but it's harder to maintain this public API in
the long run because you will need to maintain API stability for some time.
Having a complete and definitive format (RFC 2822 MIME) has a lot of value in
that perspective that a crafted Json schema does not.
Let's take some time to study that part further and build our opinion on top of
actual knowledge of the domain.
> 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" : "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 +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" : [ "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.
> {{<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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
