[ https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > {{<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