[ 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" : "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