[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762459#comment-16762459
]
Matthieu Baechler commented on JAMES-2658:
------------------------------------------
Thank you for your proposal Michael.
I'll try to answer to some questions and add some comments.
> Where to send email on failure, if the "on-failure" attribute is not "ignore".
This is a easy one: it goes to specific mailrepository, waiting for
administrator action.
> retries
I would rather propose a exponential backoff strategy with the usual
parameters: initial delay and multiplier
> async
What does it mean to be async ? we can't go ahead with the mailet pipeline
anyway because it's supposed to be sequencial.
> about service return value
Are you sure we always want to _add_ headers ? I mean, a given Header can have
several values, if you only keep adding headers, you won't be able to _replace_
some value. WDYT ?
> emailFolder
There's a lot of chance you don't have the delivery folder for a given email.
This property is usually set very late in the pipeline. So either you ensure
you always call the service at this point (I mean, the pipeline probably took
most of the decisions at this point, limiting what this new mailet can do) or
you don't expect it. WDYT ?
> Email as JSON
For now, we tried to not formalize a Email as Json format because we don't
really want to be locked by this format and AFAIK, there's no standard for
that. Why do you think sending the mail as a not-standard-json is better than
passing the raw RFC 2822 Email ?
> How often it gets call
Do you want the microservice to be called for each email recipient or only once
for a given mail ?
> Performance
Implementation of this mailet could very well degrade the reception rate of
James because we have a synchronous 1 thread per mail model. So, a blocking
HTTP call is just wasted time when looking at performance consideration. Even
more if you have to start retrying.
> LMTP
All in all, it looks like you reinvented LMTP with Mailet+HTTP. It's not bad to
reinvent, it's probably useful but we could start by understanding LMTP before
going ahead with something new, learning for decades of experience in that
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
