[jira] [Commented] (JAMES-3106) Unbinding a RabbitMQ enventGroup don't work.
[
https://issues.apache.org/jira/browse/JAMES-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054751#comment-17054751
]
Michael Bailly commented on JAMES-3106:
---
My 2 cent: there is a difference between the action of enabling/disabling a
feature, and the technical parts that are needed to have the feature working.
Currently, defining a listener (technical endpoint) enables the feature, and
there is no way to disable it.
One solution could be to set a configuration option "IMAP operations go through
Spamassassin" that is either tr or false.
> Unbinding a RabbitMQ enventGroup don't work.
>
>
> Key: JAMES-3106
> URL: https://issues.apache.org/jira/browse/JAMES-3106
> Project: James Server
> Issue Type: New Feature
> Components: mailbox, rabbitmq
>Reporter: Benoit Tellier
>Priority: Major
>
> *Problem:*
> {code:java}
> Given a running James cluster configured with additional listenerA
> When I do a rolling configuration change to remove listenerA
> Then James keeps posting events in the queue corresponding to listenerA
> without consuming it
> {code}
> To summarize we can not remove additional listeners properly even with a
> restart.
> Impact: the queue keeps growing indefinitly eventually causing a rabbitMQ
> failure.
> *Temporary workaround:*
> Upon such reconfiguration an admin needs to manually delete the corresponding
> binding using rabbitmq admin interface.
> *Long term solution:*
> We need to provide an easier way to clean this up.
> - Deleting all mailboxEvent bindings upon stop is not an option as:
>- other james servers depends on it
>- james might not be stopped in a gracefull way
> - James could be sanitizing existing bindings upon start (removing the extra
> ones) but I'm worry about uneven configuration clusters. (serverA have the
> additional listener, not serverB)
> We could as well provide a cleanup endpoint for the admin to call once the
> rolling adoption is done. Something like:
> {code:java}
> curl -XPOST htt://ip:port/eventBus/workQueues?removeUnused
> {code}
> But I don't like relying on admins to remember to call it...
> Thoughts on this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[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=16762557#comment-16762557
]
Michael Bailly commented on JAMES-2658:
---
You're probably right. Let's dig.
I need there a server-to-server kind of interaction, meaning that, FWIK, I
don't want to be connected as "userX", but as "a third party server that needs
to be called any time an email has been delivered locally, and that should be
able to add meta data to the email". Is that already available and possible in
James ?
> 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 su
[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=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:
> {{ 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"}}
> {{ } ],
[jira] [Updated] (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:all-tabpanel
]
Michael Bailly updated JAMES-2658:
--
Description:
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:
{{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.
{{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.
{{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.
{{https://server.com/api/infos; on-failure="ignore" retry="5"
retry-delay="0.5" blocking="false" />}}
or, as a second proposal
{{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".
was:
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 payl
[jira] [Updated] (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:all-tabpanel
]
Michael Bailly updated JAMES-2658:
--
Description:
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:
{{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.
{{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.
{{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.
{{https://server.com/api/infos; on-failure="ignore" retry="5"
retry-delay="0.5" blocking="false" />}}
or, as a second proposal
{{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".
was:
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 payl
[jira] [Updated] (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:all-tabpanel
]
Michael Bailly updated JAMES-2658:
--
Description:
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:
{{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.
{{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.
{{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.
{{https://server.com/api/infos; on-failure="ignore" retry="5"
retry-delay="0.5" blocking="false" />}}
or, as a second proposal
{{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".
was:
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. Th
[jira] [Updated] (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:all-tabpanel
]
Michael Bailly updated JAMES-2658:
--
Description:
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:
{{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.
{{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.
{{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.
{{https://server.com/api/infos; on-failure="ignore" retry="5"
retry-delay="0.5" blocking="false" />}}
or, as a second proposal
{{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".
was:
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
[jira] [Updated] (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:all-tabpanel
]
Michael Bailly updated JAMES-2658:
--
Description:
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:
{{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.
{{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.
{{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.
{{https://server.com/api/infos; on-failure="ignore" retry="5"
retry-delay="0.5" blocking="false" />}}
or, as a second proposal
{{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".
was:
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. Th
[jira] [Updated] (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:all-tabpanel
]
Michael Bailly updated JAMES-2658:
--
Summary: Generic mailet to call an external microservice, and add extra
information to an email (was: Generic mailet to call an external microservice,
and add extra information to a tag)
> 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_name" : "APPLICATION/PDF",}}
> {{ "content_type" : "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)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Re: James logo – the Vote is Open
Hello, yeah the last one looks great. * VOTE FOR LOGO NUMBER: 10 Cheers, Michael Le 26/09/2016 16:04, Laura Royet a écrit : Hi everyone, This emails opens the *single vote ballot* for *James log**o*. Below are the detailed explanation. **Who ca**n vote :* all the recipients of this email. Deadline :Monday, 3 October 2016 at 18:00 UTC*. *How to vo**te : **You have two options : **choosing**one of the **proposals between the 10 submitted *on : http://james.apache.org/#tabs-4 or *give a blank vote*. *So please complete the appropriate field below **:* * VOTE FOR LOGO NUMBER: * AGAINST PROPOSED LOGOS, WAIT MORE TIME FOR NEW CHOICES : The proposal collecting the most votes will become James new logo! Thank you in advance for participating. Regards, Laura -- Michael BAILLY Manager Equipe OpenPaaS Tel: 06 60 30 21 16 LINAGORA, 80 rue Roque de Fillol - 92800 PUTEAUX # Open PaaS: XXI century collaboration https://www.youtube.com/channel/UCgCZPNq1-g49VfOaxjbExlg @AwesomePaaS - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Marketing catch phrase for a promoting James website
Let me try... disclaimer: I have never been a marketing kingpin "Apache James is a highly scalable, customizable, Open Source email server. It is propelled by Java and promotes open standards." Thank you Laura to take care of the James website ! ++ Le 13/09/2016 09:55, Laura Royet a écrit : Hi I am currently working on a promoting website for James, something that would look like http://mesos.apache.org/ or https://www.docker.com/ websites to make it easier for someone reaching james.apache.org to understand what he can do with it. I work closely with Antoine, Benoit, Matthieu & Raphael to make that happen in time for James 3.0. I would need your comment about the following marketing catch phrase I've found (this one is supposed to represent the first and most visible definition of James appearing on this website) : « The Apache James Project aims at providing a a modern Mail Server product running on the JVM that promotes open standards. It's built from components so good that other projects integrate them too. Finally, it aims at being a toolkit to build your own unique Mail Service with minimal effort. » Thanks in advance for your answer. Regards, Laura Royet -- Michael BAILLY Manager Equipe OpenPaaS Tel: 06 60 30 21 16 LINAGORA, 80 rue Roque de Fillol - 92800 PUTEAUX # Open PaaS: XXI century collaboration https://www.youtube.com/channel/UCgCZPNq1-g49VfOaxjbExlg @AwesomePaaS - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
