Re: Introduction from a new member of Apache James Community

[David Leangen]

> As Quan did not succeed to send a mail to this list (...) I'm forwarding it 
> for him!

> Let me introduce myself first. My name is Tran Hong Quan. I am from Vietnam 
> and studying fourth-year at Hanoi university of science and technology.

Welcome, Quan!



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Matthieu,

My apologies for be absence. I expect to continue to be absent for the next 
couple of weeks, but I wanted to respond to your email.

> I'm not sure which message to answer in the thread so I start a new
> thread to summarize my thoughts on the various topics discussed.

No problem. However, you touch on so many points that I am not sure of the best 
way to organize this type of complex discussion. In absence of any good ideas, 
I will just respond to everything in this one thread.

I will start with one important point, then move on to the conclusion before 
responding to the rest.

>   James already works for a lot of use cases, there's nothing really
>   lacking in term of code, we should stop thinking the software should
>   be better before being happy with it. A lot of successful softwares
>   are less mature than James.

Yes, I agree. My problem was that I was never able to actually use it. So, my 
natural reaction was to try to figure out why, but I was lacking the 
documentation to do that. That got me digging into the documentation much more 
deeply than I expected to do, and took me further and further away from just 
trying to use it. 


> My conclusion is that this project is a very valuable one, written by
> some very talented developers for something like 20 years or so.

Absolutely!!


> This legacy is putting us in a very difficult situation: the codebase
> is huge, the test suite takes ages to execute, a lot of things are here
> for historical reasons but as we are careful about not breaking too
> much people deployments we don't remove enough things.

Yes, it is a difficult situation, but I think we can overcome this. The first 
step is recognizing the problems, which I think you have quite well.


> In short: we are not able to move fast, to simplify the codebase, to
> implement new things easily and finally it's hard to have fun for
> newcomers or even James veterans.

I agree. I was initially excited about using James, but I realized along the 
way that it would be a long-term commitment. I was not able to accomplish what 
I wanted because I was not able to use it, and I was also unable to understand 
it enough to make changes to be able to use it. So I was not able to complete 
my project with any success. I have changed tactic to try to accomplish this 
over the long term instead. I hope to continue to invest maybe an hour or so 
each day, but that is easier said than done.


> What I would really like is to break things! Let's remove all
> these anachronic modules, or even better: let's build James 4 by
> adopting only well selected modules, ones that are here for a purpose.

Yes, great idea.


> People could either jump to this fresh version of James or keep
> maintaining the 3.x branch. If they lack some modules that were not
> selected for James 4, they could just port these modules to the new
> APIs.

 Speaking for myself, my preference would be to jump into this version I think.


> By doing such a move, we could focus to finally solve our longstanding
> problems like: developer experience, newcomers welcoming, having a
> decent and up-to-date documentation, very easy first deployment, etc.

Ok, nice.


> What would you think of such a move ?

100% agree.


> 1. About Roadmap
> 
>   Having a roadmap is a very good way to deceive users. It's ok for a
>   company because you can somehow foresee what you'll be able to
>   achieve in the future if you care about but when it comes to people
>   and their spare time, well, life is unprecdictable.
> 
>   The less we say about the future, the better. People interested into
>   the future can always get in touch with the community and ask.

I understand your argument that we don’t want to make false promises. Hopefully 
it is clear by now that I totally agree with that idea, and that is why I have 
been pushing (hopefully not too hard) to be more “honest” about the state of 
James.

I think it is still possible to provide a “roadmap” while not making false 
promises, though. I don’t think it is an either/or. It is a “fact” that “at 
this time, this is our intent”. It does not mean that we are making any 
“promises”. So long as we make this clear, stating the current thinking of the 
community as a fact is not at all deceiving. In fact, it is helpful (1) for the 
community to have an agreement, and in writing, and (2) useful for new members 
to better understand the current thinking.

The roadmap can always be changed.


> 2. About documentation
> 
>   You definitely deserve much praises for what you did already. We
>   know that it's the missing piece for James to shine.

Ahahaha. Thanks, but I feel badly about not completing it yet. I have not given 
up, just changed gears.

>   I would just like to list what I think we lack the most:
> 
>   * examples of working setups
>   * easy-to-search documentation for details like configuration or
>   mailets
>   * guides for the most usual things: configure some mailets, 

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Benoit,

Ok, cool. I think we are making progress. 

> Would it answer some of your concerns?

Let me answer this first: yes. Thank you for patiently tolerating my 
persistence. 


> Well from what I recall, we had a nice community meeting answering that
> very question.
> 
>  - We will rework product definition, boundaries and branding. Using
> guice servers we will provide a basic/advanced/distributed server
>  - We will improve the build experience through Apache CI builds and
> migrating to graddle.
>  - Also, some contributors are implementing the final RFC-8621 JMAP release.
> 
> Maybe we should have a roadmap page somewhere so that people don't have
> to read the DEV mailing list to find these pieces of information?

That is indeed my intention, and why I am asking these questions. I am ok with 
referencing other artifacts, but I think it is important to publish the roadmap 
on the website. Of course, it can always change, that is fine. It is not a set 
contract that MUST be undertaken, but it ought to represent the current 
thoughts of the community.


> 
>> On that note, I would propose that for the 4.0 release, we clearly indicate 
>> that Spring will **NOT** be available.
> 
> +1, and a 4.0 would make the switch very clear. No ambiguity.

Ok, cool! So I think we have just now opened up a path forward.


> I believe the only work remaining toward this is
> https://github.com/apache/james-project/pull/221 (and for other guice
> servers)

I will take a look. Thanks for pointing this out.


>> It should be deprecated in an upcoming 3.x release, then “completely” 
>> eliminated in 4.0. (Perhaps some code could remain if some people really 
>> want it, but we need to make it clear in the “user contract" that it is not 
>> supported.) That would be precisely what a major release is for, IMO.
> We discussed (can't find the thread though) some years ago about the
> adoption of time based release for James server.

H. Intuitively, I am a bit skeptical, but if you ever find that discussion, 
I will read through it to hear the arguments.



> Here we could maybe:
>  - Better communicate about the release calendar (why not having it on
> the roadmap page?)
>  - Prior the release date, discuss the reach of this release (major vs
> minor) and see how we are regarding roadmap items.
>  - Also, the release process needs to be run faster...

Thank you for sharing these ideas.

I will put my thoughts together and get back to this discussion in a few days. 
I have a few other things I need to attend to now.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

>> From my point of view the most important point is to describe what
>> James does now. 
> 
> +1

Yes, I agree.

Again, I do not disagree that this is “most important”. Let me use a more 
concrete example to illustrate why it is not the **only** concern.

When I first looked into James, there was a complex grid to choose from between 
Spring and Guice. Based on the grid, it seemed to me that Spring was better.

When I started asking questions, though, I understood that Spring is not really 
being maintained anymore, or at least, more energy is being put into Guice.

Well, for me as a user trying to understand what to do, that is pretty darn 
important information! I **WANT** to know where the project is heading, because 
I need to be able to make decisions. So not only do I need to know what the 
project’s vision is (which IMO needs a lot of clarification currently), I need 
to know more concretely what the plans are for at least the next major release. 
Else, how can I decide if it’s worth investing or not?


On that note, I would propose that for the 4.0 release, we clearly indicate 
that Spring will **NOT** be available. It should be deprecated in an upcoming 
3.x release, then “completely” eliminated in 4.0. (Perhaps some code could 
remain if some people really want it, but we need to make it clear in the “user 
contract" that it is not supported.) That would be precisely what a major 
release is for, IMO.


Thoughts?

=David



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Raphaël,

> First thank you very much for your involvement into the community, I hope 
> you'll be able to continue to do so.

Well, thanks to you for your support.


> From my point of view the most important point is to describe what James does 
> now. It is what is more helpful to users (operators), and also to brand the 
> product as it allows to have a view of several capabilities of the product.

Yes, I agree with you.

For me, it is helpful to understand what the aspirations are as well, but I 
agree that “what James is now” is more important.

On that note, “what James does” to me is a part of “what James is”. 
Understanding how the community operates is also an important part of what 
James is.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Rene,

>> I have observed a few different types of approaches to OSS:
>>  * Haphazard “me” approach.
> I think you are correct, I would say that now it is more later approach as 
> well. Well at least since I started working on the project (might have been 
> different before).

Thank you very much for your comments. Yes, that is very helpful!

I fall into this trap often, and I think I am not the only one, but sometimes I 
explain what I **aspire** a project to be, not really what it is now. I think 
it is crucial to explain both. We need to be able to give proper information to 
newcomers so they can make a correct assessment. I think what you mention makes 
sense and I can work with that.

Perhaps we should just wait in case anybody else would also like to add 
something?

So I would describe James as:

 * Currently in a state of transition (this is what James is now)
 * What we aspire it to be for version xxx (I am proposing v4.0)

Just a crazy thought, but technically, I could even create the v4.0 of the 
documentation, and we could even use it almost like a specification to guide 
the development. Of course, the real work gets done based on JIRA issues, but 
the issues that get created in the first place could be matched against the 
v4.0 docs.


As we make progress, the two different versions will resemble each other more 
and more (i.e. what James **is** gets closer to what we **aspire** it to be, at 
least for v4.0).

I don’t think we need to (or ought to) set a timeline, though. There are not 
enough resources allocated to do that.


What do you think?

Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Rene,

Thanks for your reply. Sorry I just sent out my last email without having seen 
yours. My comments inline.

>> To continue with the documentation (at least on the path I have taken so 
>> far) I need to better understand the vision. That will allow me to resolve 
>> and clarify the topics previously raised regarding the community’s approach 
>> to dealing with newbies.
> 
> Well I believe a bit like Benoit on this. I think most of the time, users are 
> asking stuff because, as I raised in point 3, our documentation is outdated, 
> mixed between different products all together, not versioned, and very 
> confusing.
> 
> With the efforts made on rebranding our products towards a more 
> understandable user approach and reworking the documentation with Antora, 
> with a versioning, and having a clear separation between James flavors, it 
> would already help a lot more the users on how to use James regarding their 
> needs, and might decrease the overall need for help with the community.
> 
> Also the release process was a bit long and painful as I understood, thus we 
> were only updating the doc when doing a release, so lots of fixes stay 
> hanging for a while. I believe with Antora and Eugen work to automate the 
> build and website release he did (I hope I'm not wrong?), it might make it 
> much easier as well to keep our documentation up-to-date.

Great! So it sounds like there **is** some interest in taking a more 
user-centric approach. That is exactly what I am trying to gauge and 
understand. 


> I believe as well trying to add a bunch of how-tos regarding the topics that 
> an admin might likely be interested to setup with James or what seems to be 
> recurrent struggles of users might help too.

That would be great!!


> Honestly thank you greatly for all the time and thinking you have been 
> putting into this new James documentation with a more user-focused mindset. I 
> believe it helped the project greatly being more community friendly !

Thank you for letting me know. I am relieved that it is useful.  In that case, 
I am happy to continue, albeit at an even slower pace.

Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Benoit,

> I think I did answer in that thread already.

Yes, you did. And thank you.

>> To continue with the documentation (at least on the path I have taken so 
>> far) I need to better understand the vision. That will allow me to resolve 
>> and clarify the topics previously raised regarding the community’s approach 
>> to dealing with newbies.
> This sentence sounds like the "support/warranty" discussion turned into
> a blocker for you.

It is not a blocker in the sense that regardless of the approach the community 
wants to take, I will continue one way or the other.

However, in order to document, I need to understand. In that respect it is a 
blocker because I still do not fully understand how this community is working. 
I will write more below about what I mean.

> I think instead of using blockers we should propose consensual solutions.

All for it!

> The approach that emerged from ongoing proposal would be "Through better
> branding and documentation, end user would need less support" eventually
> making most people happy, without requiring SLAs from community members.

It is interesting that you interpreted it this way. Allow me to try to clarify 
my thinking.



What I am trying to understand is (1) this community’s vision, and (2) a 
slightly deeper understanding of its approach to OSS.

I don’t really have proper vocabulary, so I’ll try to explain in my own words. 
Perhaps somebody has already done research on this topic so can express these 
ideas better. If you know of any such document, please do let me know. In the 
meantime, here is my layman’s explanation.



I have observed a few different types of approaches to OSS:

 * Centered on a specification. The spec development has a formal process, and 
the spec becomes the driving force. There is a “reference implementation” to 
show that the spec works as intended. In this case, the clarity relates to the 
spec. There is engagement from the community to make implement the spec in a 
way that “works”. The clarity for the user in this case is that they know what 
they can expect. (Perhaps OSGi is a great example of this approach.)

 * Centered on a clear corporate vision. As a typical case, a company has 
developed a product and has decided to open source it. What the product does is 
clearly documented, as is the type of support that a user can receive 
(community version or commercial version). Again, for the user, there is 
clarity in terms of what they can expect to receive. (Maybe something like 
Docker would fit this model? Or Elasticsearch?)

 * Driven by a clear vision and objective. The scope of the product is very 
clear, and there is a commitment (for whatever reason) to make it “work”. By 
extension, this means that the meaning of “it works” is very precisely 
understood. (Maybe Ant, Maven, and Gradle are good examples, because what is 
meant by a “build tool” is pretty well understood.)

 * Haphazard “me” approach. In this case, there is no central driver (spec, 
company, clear vision). The product evolves more based on the individual 
contributions of the members, which themselves are based almost entirely on 
what the contributors need for themselves. Unless a contributor has their own 
specific need and evolves the product to suite that need, then there is little 
chance that the product will move. Because it is unpredictable what each 
individual contributor will need, from the user’s perspective the development 
is haphazard. There is little clarity in terms of what they can expect to get, 
or if the product will continue to be maintained. If they want it to work, they 
will have to become a contributor themselves, as there there are no guarantees.


There is no “right” or “wrong”, or even “better” by the way.


From my understanding so far, I think that James seems to fit the latter 
approach. Yes, it relates to a few specifications, but James is not (as I 
understood) willing to “commit” to being a reference implementation for SMTP, 
IMAP, JMAP etc. Yes, there is some vision and some objectives, but nobody is 
willing to commit to ensuring that the product works according to the 
objectives, and as far as I can tell, the objectives are not entirely precisely 
defined. So, based on what I know so far, it seems to fit best the last model.

All I want to know is: is this intended?


Again, all I am trying to do is get clarity. I need the clarity if I am to 
describe James to outsiders. The first, fundamental, basic questions anyone 
will want to know is: What is James? Can I use this? What can I expect?

If we do not provide a clear and honest answer, as far as I am concerned it is 
a misrepresentation, and is not ethical. I am not trying suggest which approach 
to take, I am simply trying to understand this community’s intentions with more 
clarity in order to properly represent it.

Your help would be greatly appreciated. 


Cheers,
=David


-
To 

[jira] [Commented] (JAMES-3187) Update James Documentation

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185106#comment-17185106
 ] 

David Leangen commented on JAMES-3187:
--

{quote}[https://github.com/apache/james-project/pull/243] adds the community 
section of the new documentation
{quote}

[~rcordier], thank you so much for this!

I am still [trying to engage the 
community|https://www.mail-archive.com/server-dev@james.apache.org/msg68306.html]
 regarding this (and related) issues, but am having a tough time. Maybe I am 
approaching this the wrong way?

If I can get some more feedback, I will continue where you left off. Thanks 
again for doing that!

> Update James Documentation
> --
>
> Key: JAMES-3187
> URL: https://issues.apache.org/jira/browse/JAMES-3187
> Project: James Server
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 3.5.0
>    Reporter: David Leangen
>Priority: Major
>  Time Spent: 46h 10m
>  Remaining Estimate: 0h
>
> This is a backported issue relating to an ongoing project to redo the 
> documentation in Antora.



--
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

Re: [Discussion] Road to 4.0

[David Leangen]

Hello,

I am still trying to get a sense of the community’s vision, and it’s thoughts 
relating to how to treat users. Unfortunately I have not heard too many 
comments so far on this topic. Trying to read between the lines, I could think 
of 4 potential conclusions:

 1. People are still on summer holidays and don’t have the time to spend
 2. I have taken a wrong or confusing approach to the topic, so people don’t 
know what to answer
 3. This is already documented somewhere so the assumption is that I already 
know it
 4. There is not much interest in discussing the the topic of “users”

To continue with the documentation (at least on the path I have taken so far) I 
need to better understand the vision. That will allow me to resolve and clarify 
the topics previously raised regarding the community’s approach to dealing with 
newbies.

By the way, this project was much more difficult that I had anticipated. I no 
longer have much time to dedicate, but I pledge to continue, albeit at a slower 
pace and in the background, so long as I continue to get engagement from the 
community members. My main goal is to help document the state of James and the 
community, and the secondary goal that I discovered in the process is to point 
out gaps and potential areas of improvement. Thanks again for all the support!!

Cheers,
=David



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3360) Change "User Repository" to "User Directory"

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180895#comment-17180895
 ] 

David Leangen commented on JAMES-3360:
--

Thank you for the clarification.
{quote}bq. UserRepository is an interface that other people implement when they 
store users in other places.
{quote}
Yes, likely a "UserRepository" is still a useful pattern to use. We still need 
to store the data somewhere, right?

So overall what I understand you are saying is: you don't think that "user" is 
a domain concept: it is only relevant on the technical level. Therefore, what 
we call it is not so important. (If "user" is not a domain concept, then I 
would agree with your assessment.)

You also seem to imply that you do not subscribe to the idea of maintaining 
consistency (i.e. you don't mind using one term in the user docs, and a 
different term in the code). (I do not agree with this approach. I think we 
need consistency throughout the entire stack.)

Therefore, you do not see the value in making the change, especially because 
there are costs (and the cost of breaking the API is high). (My decision 
depends on whether or not "user" is considered as a domain concept or not. If 
it is, then the code ought to reflect the domain, and it must be incrementally 
improved, even at the cost of breaking the current API. If not, then I agree 
that we don't need the trouble.)

So if we could have some consensus around this point (is "user" a domain 
concept or not), if we agree that it is not, then I will reconsider how to 
write the documentation and will close this issue.

> Change "User Repository" to "User Directory"
> 
>
> Key: JAMES-3360
> URL: https://issues.apache.org/jira/browse/JAMES-3360
>     Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Priority: Major
>
> I wonder if there isn't a wording problem here.
> I understand that the idea is to have a place to store user data. However, 
> the naming looks at the problem from a purely technical point of view. A 
> "Repository" by definition is a place to "put" something. For example, in the 
> real world, a document repository is an actual place to put documents.
> The wording suggests that we have some place where we put people, which seems 
> very strange to me if we correspond the idea to the real world. It creates a 
> very strange mental model for me.
> I think the concept that should be modeled here is more along the lines of a 
> "Directory". We have a kind of index that gives useful information about how 
> to locate users. It is not a place where we take people and lock them up. 
> Rather, it is a list of information about people. Does that make sense?
> [Here is a 
> definition|https://dictionary.cambridge.org/dictionary/english/directory] we 
> could use:
> {quote}a list of telephone numbers, names, addresses, or other information
> {quote}
> Note that if the Repository is never exposed to anybody except implementors, 
> and it really is just a place to put data, then this issue would not bother 
> me. However, it is my understanding from writing the new documents that this 
> concept is actually exposed, so I think the concept needs to be fixed.



--
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-3360) Change "User Repository" to "User Directory"

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180464#comment-17180464
 ] 

David Leangen commented on JAMES-3360:
--

Thank you for commenting. I think your comment is kinda proving my point about 
the "technical solution" versus the "model". I will try to explain in my 
comments.
{quote}The change is mostly wording as you say and IMO not something to spend 
much time on it .
{quote}
Right, but a "model" is essentially "just wording". Words express concepts. 
Saying we don't care about the words is the same as saying that we don't care 
about the model.

Are you saying that you don't care about the model?
{quote}As long as it's documented how it works we can name it however we want.
{quote}
True. We could even call it an "apple" if we want. I'm not sure that helps with 
comprehension. The whole point of a model is to try to reduce cognitive 
dissonance. But again, if we don't care about models, then what you say is 
entirely correct.
{quote}I think the name comes from the repository pattern which is not far from 
what it does: [https://deviq.com/repository-pattern/]
{quote}
The repository pattern used by DDD is about persisting domain objects. It is 
not related to actual modeling of the domain. It is important not to confuse 
the two. "Repository" is a technical solution that DDD proposes "to help keep a 
domain focus" (cf p. 107 of "Domain Driven Design" by Eric Evans), while the 
"Directory" concept I am suggesting is an actual model of the domain (looking 
up users).
{quote}Directory is more of a read-only thing (not necessarily) while 
repository is read/write.
{quote}
I don't think so. Otherwise how would a directory get populated with user 
information?
{quote}[https://www.merriam-webster.com/dictionary/repository]
{quote}
The definition I see here is: "a place, room, or container where something is 
deposited or stored".

I think this actually proves my point. We do not store users in a room. Yes, we 
store user **data**. So repository is for storing data, i.e. a technical 
solution if the concept of "user" is actually important in the email domain, 
which I believe it is.

If I am mistaken, please let me know and I will be the first to close this 
issue.

So do we only care about the technical solution to the problem, and don't give 
a rat's a** about the model (assuming "users" are part of the model)? Because 
if we actually care about modeling, then we need to be able to decouple our 
thinking from the technical solution of the model.

> Change "User Repository" to "User Directory"
> 
>
> Key: JAMES-3360
>     URL: https://issues.apache.org/jira/browse/JAMES-3360
> Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Priority: Major
>
> I wonder if there isn't a wording problem here.
> I understand that the idea is to have a place to store user data. However, 
> the naming looks at the problem from a purely technical point of view. A 
> "Repository" by definition is a place to "put" something. For example, in the 
> real world, a document repository is an actual place to put documents.
> The wording suggests that we have some place where we put people, which seems 
> very strange to me if we correspond the idea to the real world. It creates a 
> very strange mental model for me.
> I think the concept that should be modeled here is more along the lines of a 
> "Directory". We have a kind of index that gives useful information about how 
> to locate users. It is not a place where we take people and lock them up. 
> Rather, it is a list of information about people. Does that make sense?
> [Here is a 
> definition|https://dictionary.cambridge.org/dictionary/english/directory] we 
> could use:
> {quote}a list of telephone numbers, names, addresses, or other information
> {quote}
> Note that if the Repository is never exposed to anybody except implementors, 
> and it really is just a place to put data, then this issue would not bother 
> me. However, it is my understanding from writing the new documents that this 
> concept is actually exposed, so I think the concept needs to be fixed.



--
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] [Created] (JAMES-3360) Change "User Repository" to "User Directory"

[David Leangen (Jira)]

David Leangen created JAMES-3360:


 Summary: Change "User Repository" to "User Directory"
 Key: JAMES-3360
 URL: https://issues.apache.org/jira/browse/JAMES-3360
 Project: James Server
  Issue Type: Improvement
    Reporter: David Leangen


I wonder if there isn't a wording problem here.

I understand that the idea is to have a place to store user data. However, the 
naming looks at the problem from a purely technical point of view. A 
"Repository" by definition is a place to "put" something. For example, in the 
real world, a document repository is an actual place to put documents.

The wording suggests that we have some place where we put people, which seems 
very strange to me if we correspond the idea to the real world. It creates a 
very strange mental model for me.

I think the concept that should be modeled here is more along the lines of a 
"Directory". We have a kind of index that gives useful information about how to 
locate users. It is not a place where we take people and lock them up. Rather, 
it is a list of information about people. Does that make sense?

[Here is a 
definition|https://dictionary.cambridge.org/dictionary/english/directory] we 
could use:
{quote}a list of telephone numbers, names, addresses, or other information
{quote}
Note that if the Repository is never exposed to anybody except implementors, 
and it really is just a place to put data, then this issue would not bother me. 
However, it is my understanding from writing the new documents that this 
concept is actually exposed, so I think the concept needs to be fixed.



--
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

Re: Which repositories are we using and going to document? Let's retire the ones we don't

[David Leangen]

> I do think we might want to leverage this opportunity to close
> low-traffic unused mailing lists. This includes:



My 2 cents:

From the user perspective, I think it would be desirable to trim down the 
number of mailing lists. 



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [Discussion] Road to 4.0

[David Leangen]

Hi Benoit,

Thank you for responding.

>> I wanted to tie together a few ongoing threads and make a proposal for the 
>> road to a 4.0 release. 
> 
> I'm uncomfortable with the 4.0 release switch. It gives the impression
> that "much" needs to change whilewhat we need is to re-brand, and better
> document what exists.

I see.

I agree that there isn’t really that much that needs to be changed from a 
technical perspective. My thought was that from the user perspective, there 
really are some very large changes being made. It seems to me that even if 
technically the changes are small, from an objective / orientation perspective 
this is a huge change.

Do you think it will be as easy to explain these changes to the public even 
with a minor release?


>> By the way, to coincide with the release, if the objectives are clear, 
>> perhaps there is a commercial organization (or individual) who would be 
>> willing to provide paid-for professional support starting from 4.0?
> Linagora (company for which I am working) already proposes these
> services. We already carried out several support / development contracts
> for Apache James.

Thanks! Is there a website page or something with details of this service 
offering?

I did a quick search for “Linagora James development” and got this hit:

  —> https://linagora.com/open-source-technologies/apache-james 



>> I think it would help complete the offering, and hopefully provide a 
>> commercial opportunity as well in a way that is beneficial to all, including 
>> the James community. We just need to ensure that the “contract” is very 
>> clear, and that we avoid any potential conflicts of interest. I think we 
>> should include this item in the scope of the discussion as well. 
> 
> I'm not sure an Apache project is entitled to broadcast details of
> comercial offers. I believe "listing" service provider is enough. It
> should be up to the service providers to detail their offer on their own
> website (referenced via an hyper-link)

Good point. Need to follow Apache rules. My concern is about clarity, 
especially because there could be a potential appearance of a conflict of 
interest between Linagora and the James project.

My thought was that if the objectives and scope of James is made very clear, 
then any potential conflict of interest would be resolved, and also it would 
provide clarity to current and potential users of James.



>> (Just a thought, but maybe the “Distributed James” could be a commercial 
>> offering, rather than a community offering??)
> I strongly believe the "distributed server" is a differentiator for Apache 
> James and helps satisfy some of the community needs.

Ok, that’s fair. Then I guess we’ll have to figure out a different boundary.



>> To resolve this thread, I will be satisfied once we have a clear statement 
>> of objectives regarding the 4.0 release.
> I do agree with the already discussed items (documentation & re-branding)

For my benefit, would you mind pasting a very short summary here so that I can 
understand more precisely what it is you are referring to?

By the way, I also want to resolve the “community” discussion because I think 
it is related, but perhaps that is too ambitious for this thread.


Cheers,
=David

[Discussion] Road to 4.0

[David Leangen]

Hello!

I wanted to tie together a few ongoing threads and make a proposal for the road 
to a 4.0 release. My assumption is that there currently is not roadmap to 4.0. 
If I am mistaken, please do let me know and I will adapt.

I think by now it is clear that, although a great project with TONS of great 
work put into it by some very dedicated people over several years, over time 
James has drifted away from having a user focus. (I’ll say “user” here because 
it is more natural, but I really mean “Operator” as we defined recently). What 
this means is:

 * It is difficult for new users to understand how James works
 * It is difficult to get James working
 * It is not easy to understand how to configure James
 (or even to understand what all the different configurations are)

I don’t think this was ever intended, but it just kinda happened over time. I 
think it is understandable, as James is a very complex project. Maintaining a 
working system of this scale by a small team of volunteers is not at all an 
easy task. I am not at all trying to suggest that this is a “bad” thing in any 
way, so please don’t get me wrong.

I get the feeling that there has been a lot of support in the community to 
shift towards making James more user-friendly, and that it shouldn’t require a 
huge effort because there are so many good things already baked into the 
project. The current direction seems to be:

 * Redo the documentation (already underway, though taking more time than 
expected)
 * Have a “Basic Server” entry-level offering that is ideally very easy to 
install and operate
 * Have an “Extensible Server” offering that shows where James really shines 
(i.e. its extensibility)
 —> Include some kind of “build project” that helps operators build the 
James they want
  * Have a “Distributed Server” offering for more heavy-duty environments

(There are a few other servers as well, but maybe they are more 
development-oriented??)

My intention in this thread is to set a very clear objective for a 4.0 release. 
I would like to propose that for the 4.0 release, we start to make the 
objectives more user-oriented. I would like to propose that as part of setting 
our objectives for 4.0, we adhere to the following:

 * Set clear metrics to determine if the objectives are met or not
 * Make the metrics user-oriented

As part of this release, I would like to resolve how the community sees its 
role. In the discussion we had last time, it seemed to be very inward focused 
(what do I get out of this; how do I ensure that I don’t feel stuck doing 
something I don’t want to do) instead of being outward focused (what does the 
user get, how should the user expect to benefit). I would argue that any 
user-oriented documentation should be for the user’s benefit, and ought to be 
user-focused. I think we need a clear resolution, and I think it is related to 
the 4.0 objective.

By the way, to coincide with the release, if the objectives are clear, perhaps 
there is a commercial organization (or individual) who would be willing to 
provide paid-for professional support starting from 4.0? I think it would help 
complete the offering, and hopefully provide a commercial opportunity as well 
in a way that is beneficial to all, including the James community. We just need 
to ensure that the “contract” is very clear, and that we avoid any potential 
conflicts of interest. I think we should include this item in the scope of the 
discussion as well. (Just a thought, but maybe the “Distributed James” could be 
a commercial offering, rather than a community offering??)


To resolve this thread, I will be satisfied once we have a clear statement of 
objectives regarding the 4.0 release.

Cheers,
=David



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3260) Explore building Apache James with Gradle

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170764#comment-17170764
 ] 

David Leangen commented on JAMES-3260:
--

Hi [~ieugen]. The gradle build is awesome! Thanks so much for doing this.

I am wondering what the process is to keep it up to date. I tried running the 
gradle build today, but it exits with errors.

My goal is to adapt it so I can release snapshots. It would be ideal if James 
released these daily (I think some Apache projects do that), but in the 
meantime I would be satisfied to be able to do that successfully to my own 
Nexus server.

I need this so I can attempt to have a proper build/deploy process for my 
custom James server.

I need that so I can continue with my Documentation project.

> Explore building Apache James with Gradle
> -
>
> Key: JAMES-3260
> URL: https://issues.apache.org/jira/browse/JAMES-3260
> Project: James Server
>  Issue Type: Improvement
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
>  Time Spent: 10.5h
>  Remaining Estimate: 0h
>
>  Creating an issue to track the process of using Gradle for building Apache 
> James.
> There have been a few discussions on this topic from multiple parties.
> The main benefit is having faster builds which Maven is unable to provide 
> because of it's limitations on how it approaches build life-cycle and 
> caching. 
> We should take care of:
> * all that is related to release and deploy (but this can be taken from other 
> Apache projects already using Gradlle)
> * the site building (but this should disappear with the migration to Antora)
> * the mailets plugin
> * checking Spring build
> * adding partial tests on JMAP integration (allowing to run only some smoke 
> tests on some big integration tests suite)
> * adding and configuration the checkstyle plugin
> * updating the Jenkins build
> * documenting the migration for all the users that are building James 
> themselves



--
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

Re: Which repositories are we using and going to document? Let's retire the ones we don't

[David Leangen]

> Migrating is not sexy work but is easier than writing new documentation.

Conditional on the structure and content being in a desirable state, I would 
agree with this generalization. In this case, though, I don’t feel the 
condition is me, so I think we’ll have to agree to disagree.


> I've added edit-url capabilites, changed the homepage to be in james-site and 
> renamed main to  james-project 
> .https://james.staged.apache.org/jdkim/0.3-SNAPSHOT/index.html .

Thanks!


> I'm curios how the structure is going to evolve.

Me, too!


Cheers,
=David



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Which repositories are we using and going to document? Let's retire the ones we don't

[David Leangen]

> I've decided to add docs stubs to all repositories.
> I'm going to start migrating the documentation for the popular libraries and 
> then decide what to do with the others (start the retiring process most 
> likely).

Awesome! Nice initiative. Thanks!!


> Anyone up for a documentation migration party?

As I mentioned before, I am quite skeptical of just migrating documents. I 
won’t stop you, but I’m not sure it would add value, because I think the sites 
need to be rewritten from scratch. So taking the sources from where they are 
now would be just fine IMO.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168309#comment-17168309
 ] 

David Leangen commented on JAMES-3226:
--

Good point to re-evaluate the module naming.

"main" only makes sense if there is a top-level view that provides an aggregate 
view, but as you pointed out, if we can have an independent index page, that 
should probably be enough, so a "main" (or "top" or whatever) becomes 
unnecessary. So yes, I agree to renaming "main".

The Antora module names should exactly match the actual James module names. 
That means that the debate is **not** about how to name Antora modules. If 
there is a problem with naming, it ought to be brought up in the project itself.

The documentation is intended to describe the project as it is, regardless of 
whether it is "right" or "wrong", or is intended to be changed.

But: do we follow the exact structure of the projects? It looks like 
james-project is so much larger than, for example, jsieve. It may be warranted 
to associate Antora modules to james-project modules.

So the question you're really asking is: do we have a single Antora module for 
the entire james-project? Or because of the large scope of james-project, do we 
break it down into sub-modules.

I propose we start with james-project, and defer that decision until later. 
Does that sound ok?

> Provide a process around documentation publishing and deployment
> 
>
> Key: JAMES-3226
> URL: https://issues.apache.org/jira/browse/JAMES-3226
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: Captură de ecran de la 2020-07-31 02-34-10.png
>
>
> We have started working on the documentation and it's great.
> We should also document the processes around documentation:
> - when we publish the docs
> - how to publish the docs
> - where to publish the docs
> - when we retire old docs ?!
> This task should aggregate discussion and decisions.
> The process should be written as asciidoc.
> We decided to use antora as a documentation system so the features are going 
> to depend on that technology. 
> We should have documentation for every release we make. 
> This is important since  people don't upgrade immediately after release and 
> might use an older release for some time.
> I'm not sure if the documentation for all versions should be online.
> We can build zip archives of each documentation release and include it in the 
> binary release  or publish them for download next to it. 
> This way we can keep only the latest 1-3 versions online.



--
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] [Comment Edited] (JAMES-3226) Provide a process around documentation publishing and deployment

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168302#comment-17168302
 ] 

David Leangen edited comment on JAMES-3226 at 7/30/20, 11:38 PM:
-

Should there be a kind of "top" page with a top-level view that explains each 
of these (and links to them)? Where would that page go?

Maybe have an additional, smallish "James" site that gives the very top-level 
overview? Or should that top-level view be outside of Antora?


was (Author: dleangen):
Should there be a kind of "top" page with a top-level view that explains each 
of these (and links to them)? Where would that page go?

> Provide a process around documentation publishing and deployment
> 
>
> Key: JAMES-3226
> URL: https://issues.apache.org/jira/browse/JAMES-3226
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: Captură de ecran de la 2020-07-31 02-34-10.png
>
>
> We have started working on the documentation and it's great.
> We should also document the processes around documentation:
> - when we publish the docs
> - how to publish the docs
> - where to publish the docs
> - when we retire old docs ?!
> This task should aggregate discussion and decisions.
> The process should be written as asciidoc.
> We decided to use antora as a documentation system so the features are going 
> to depend on that technology. 
> We should have documentation for every release we make. 
> This is important since  people don't upgrade immediately after release and 
> might use an older release for some time.
> I'm not sure if the documentation for all versions should be online.
> We can build zip archives of each documentation release and include it in the 
> binary release  or publish them for download next to it. 
> This way we can keep only the latest 1-3 versions online.



--
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-3226) Provide a process around documentation publishing and deployment

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168302#comment-17168302
 ] 

David Leangen commented on JAMES-3226:
--

Should there be a kind of "top" page with a top-level view that explains each 
of these (and links to them)? Where would that page go?

> Provide a process around documentation publishing and deployment
> 
>
> Key: JAMES-3226
> URL: https://issues.apache.org/jira/browse/JAMES-3226
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: Captură de ecran de la 2020-07-31 02-34-10.png
>
>
> We have started working on the documentation and it's great.
> We should also document the processes around documentation:
> - when we publish the docs
> - how to publish the docs
> - where to publish the docs
> - when we retire old docs ?!
> This task should aggregate discussion and decisions.
> The process should be written as asciidoc.
> We decided to use antora as a documentation system so the features are going 
> to depend on that technology. 
> We should have documentation for every release we make. 
> This is important since  people don't upgrade immediately after release and 
> might use an older release for some time.
> I'm not sure if the documentation for all versions should be online.
> We can build zip archives of each documentation release and include it in the 
> binary release  or publish them for download next to it. 
> This way we can keep only the latest 1-3 versions online.



--
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-3226) Provide a process around documentation publishing and deployment

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168301#comment-17168301
 ] 

David Leangen commented on JAMES-3226:
--

Nice! That is exactly what I had in mind with the modules, and how to integrate 
them. Good work!

> Provide a process around documentation publishing and deployment
> 
>
> Key: JAMES-3226
> URL: https://issues.apache.org/jira/browse/JAMES-3226
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: Captură de ecran de la 2020-07-31 02-34-10.png
>
>
> We have started working on the documentation and it's great.
> We should also document the processes around documentation:
> - when we publish the docs
> - how to publish the docs
> - where to publish the docs
> - when we retire old docs ?!
> This task should aggregate discussion and decisions.
> The process should be written as asciidoc.
> We decided to use antora as a documentation system so the features are going 
> to depend on that technology. 
> We should have documentation for every release we make. 
> This is important since  people don't upgrade immediately after release and 
> might use an older release for some time.
> I'm not sure if the documentation for all versions should be online.
> We can build zip archives of each documentation release and include it in the 
> binary release  or publish them for download next to it. 
> This way we can keep only the latest 1-3 versions online.



--
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-3348) Problems with sieve: missing persistant class declaration

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166419#comment-17166419
 ] 

David Leangen commented on JAMES-3348:
--

However, I still don't have permissions in JIRA, so I can't change the 
resolution of this issue.

> Problems with sieve: missing persistant class declaration
> -
>
> Key: JAMES-3348
> URL: https://issues.apache.org/jira/browse/JAMES-3348
> Project: James Server
>  Issue Type: Improvement
>  Components: data, jpa
>Reporter: Benoit Tellier
>Priority: Major
>
> As reported by David in 
> https://www.mail-archive.com/server-dev@james.apache.org/msg67980.html
> JPA products fails to load sieve related data:
> {code:java}
> 14:31:44.887 [ERROR] o.a.j.t.m.j.d.SieveExecutor - Cannot evaluate Sieve 
> script 
> for user 
> org.apache.openjpa.persistence.ArgumentException: There is no query with the 
> name "findActiveByUsername" defined for any of the known persistent classes: 
> {code}
> We are missing the following persistant class declarations:
> {code:java}
> org.apache.james.sieve.jpa.model.JPASieveQuota
> org.apache.james.sieve.jpa.model.JPASieveScript
> {code}



--
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-3348) Problems with sieve: missing persistant class declaration

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166418#comment-17166418
 ] 

David Leangen commented on JAMES-3348:
--

I confirm that with this fix, the problem is resolved.

> Problems with sieve: missing persistant class declaration
> -
>
> Key: JAMES-3348
> URL: https://issues.apache.org/jira/browse/JAMES-3348
> Project: James Server
>  Issue Type: Improvement
>  Components: data, jpa
>Reporter: Benoit Tellier
>Priority: Major
>
> As reported by David in 
> https://www.mail-archive.com/server-dev@james.apache.org/msg67980.html
> JPA products fails to load sieve related data:
> {code:java}
> 14:31:44.887 [ERROR] o.a.j.t.m.j.d.SieveExecutor - Cannot evaluate Sieve 
> script 
> for user 
> org.apache.openjpa.persistence.ArgumentException: There is no query with the 
> name "findActiveByUsername" defined for any of the known persistent classes: 
> {code}
> We are missing the following persistant class declarations:
> {code:java}
> org.apache.james.sieve.jpa.model.JPASieveQuota
> org.apache.james.sieve.jpa.model.JPASieveScript
> {code}



--
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

Re: Problems with sieve

[David Leangen]

Awesome! Thank you, Benoit.

I updated, recompiled, reran, and confirmed that the problem has gone away.


Cheers,
=David



> On Jul 28, 2020, at 18:36, Tellier Benoit  wrote:
> 
> Hello David.
> 
> I found the issue. org.apache.james.sieve.jpa.model.JPASieveQuota &
> org.apache.james.sieve.jpa.model.JPASieveScript are not registered as
> persistant class hence the failure.
> 
> I opened https://issues.apache.org/jira/browse/JAMES-3348 & a fix for
> this here: https://github.com/apache/james-project/pull/242.
> 
> Cheers,
> 
> Benoit
> 
> Le 28/07/2020 à 12:36, David Leangen a écrit :
>> Hello,
>> 
>> I am having trouble figuring out the origin of this problem:
>> 
>> 14:30:10.458 [INFO ] o.a.j.s.SendMailHandler - Successfully spooled mail 
>> Mail1595914206122-99a764fb-1097-4614-a1c2-022d0b331bee from 
>> MaybeSender{mailAddress=Optional[user01@test.local]} on 
>> localhost/0:0:0:0:0:0:0:1 for [user01@test.local]
>> 14:30:34.797 [INFO ] o.a.j.p.n.BasicChannelUpstreamHandler - Connection 
>> closed for 0:0:0:0:0:0:0:1
>> 14:31:44.887 [ERROR] o.a.j.t.m.j.d.SieveExecutor - Cannot evaluate Sieve 
>> script for user 
>> org.apache.openjpa.persistence.ArgumentException: There is no query with the 
>> name "findActiveByUsername" defined for any of the known persistent classes: 
>> [org.apache.james.mailbox.jpa.quota.model.MaxGlobalMessageCount, 
>> org.apache.james.mailbox.jpa.mail.model.JPAUserFlag, 
>> org.apache.james.mailbox.jpa.quota.model.MaxUserStorage, 
>> org.apache.james.mailbox.jpa.mail.model.openjpa.AbstractJPAMailboxMessage, 
>> org.apache.james.mailbox.jpa.quota.model.JpaCurrentQuota, 
>> org.apache.james.mailbox.jpa.user.model.JPASubscription, 
>> org.apache.james.rrt.jpa.model.JPARecipientRewrite, 
>> org.apache.james.mailbox.jpa.mail.model.JPAMailboxAnnotation, 
>> org.apache.james.mailbox.jpa.quota.model.MaxDomainMessageCount, 
>> org.apache.james.mailbox.jpa.quota.model.MaxGlobalStorage, 
>> org.apache.james.mailbox.jpa.mail.model.JPAMailboxAnnotationId, 
>> org.apache.james.mailbox.jpa.mail.model.JPAMailbox, 
>> org.apache.james.mailrepository.jpa.JPAUrl, 
>> org.apache.james.mailbox.jpa.quota.model.MaxDomainStorage, 
>> org.apache.james.mailbox.jpa.quota.model.MaxUserMessageCount, 
>> org.apache.james.domainlist.jpa.model.JPADomain, 
>> org.apache.james.user.jpa.model.JPAUser, 
>> org.apache.james.mailbox.jpa.mail.model.JPAProperty, 
>> org.apache.james.mailbox.jpa.mail.model.openjpa.JPAMailboxMessage].
>>at 
>> org.apache.openjpa.meta.MetaDataRepository.getQueryMetaDataInternal(MetaDataRepository.java:1982)
>>at 
>> org.apache.openjpa.meta.MetaDataRepository.getQueryMetaData(MetaDataRepository.java:1963)
>>at 
>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:1200)
>>at 
>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:1191)
>>at 
>> org.apache.james.sieve.jpa.JPASieveRepository.findActiveSieveScript(JPASieveRepository.java:153)
>>at 
>> org.apache.james.sieve.jpa.JPASieveRepository.lambda$findActiveSieveScript$6(JPASieveRepository.java:147)
>>at 
>> com.github.fge.lambdas.functions.FunctionChainer.lambda$sneakyThrow$49(FunctionChainer.java:74)
>>at 
>> org.apache.james.backends.jpa.TransactionRunner.runAndRetrieveResult(TransactionRunner.java:65)
>>at 
>> org.apache.james.sieve.jpa.JPASieveRepository.findActiveSieveScript(JPASieveRepository.java:146)
>>at 
>> org.apache.james.sieve.jpa.JPASieveRepository.getActivationDateForActiveScript(JPASieveRepository.java:133)
>>at 
>> org.apache.james.transport.mailets.jsieve.ResourceLocator.get(ResourceLocator.java:66)
>>at 
>> org.apache.james.transport.mailets.jsieve.delivery.SieveExecutor.sieveMessage(SieveExecutor.java:127)
>>at 
>> org.apache.james.transport.mailets.jsieve.delivery.SieveExecutor.execute(SieveExecutor.java:122)
>>at org.apache.james.transport.mailets.Sieve.service(Sieve.java:75)
>> 
>> 
>> Any hints?
>> 
>> Thank you!
>> =David
>> 
>> 
>> -
>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
>> For additional commands, e-mail: server-dev-h...@james.apache.org
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
> 


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: A copy was not placed in your sent folder

[David Leangen]

Problem solved.

It appears that the problem was due to a bad volume configuration. That makes 
sense, since the problem only popped up when I started using Docker.

Cheers,
=David


> On Jul 28, 2020, at 15:57, David Leangen  wrote:
> 
> 
> Hi!
> 
> Any ideas why I would get this error in my client? (attached image)
> 
> I was running locally without an issue. This error popped up when I tried 
> running with Docker.
> 
> 
> Thanks!
> =David
> 
> 
> 


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

A copy was not placed in your sent folder

[David Leangen]

Hi!

Any ideas why I would get this error in my client? (attached image)

I was running locally without an issue. This error popped up when I tried 
running with Docker.


Thanks!
=David

[jira] [Updated] (JAMES-3346) Configure Elasticsearch

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen updated JAMES-3346:
-
Summary: Configure Elasticsearch  (was: Configure Lucene)

> Configure Elasticsearch
> ---
>
> Key: JAMES-3346
> URL: https://issues.apache.org/jira/browse/JAMES-3346
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> Lucene files are being stored in the root directory. The should be configured 
> to be placed in a location that could be made into a volume.



--
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-3346) Configure Lucene

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166178#comment-17166178
 ] 

David Leangen commented on JAMES-3346:
--

There is [an explanation on the 
website|https://james.apache.org/server/config-elasticsearch.html], but it does 
not explain how to configure the location of the output.

> Configure Lucene
> 
>
> Key: JAMES-3346
> URL: https://issues.apache.org/jira/browse/JAMES-3346
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> Lucene files are being stored in the root directory. The should be configured 
> to be placed in a location that could be made into a volume.



--
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-3346) Configure Lucene

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166175#comment-17166175
 ] 

David Leangen commented on JAMES-3346:
--

I found what I think is a [default elasticsearch config 
file|https://github.com/apache/james-project/blob/master/dockerfiles/run/guice/cassandra/destination/conf/elasticsearch.properties].
 I'll try working with this.

> Configure Lucene
> 
>
> Key: JAMES-3346
> URL: https://issues.apache.org/jira/browse/JAMES-3346
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> Lucene files are being stored in the root directory. The should be configured 
> to be placed in a location that could be made into a volume.



--
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

Problems with sieve

[David Leangen]

Hello,

I am having trouble figuring out the origin of this problem:

14:30:10.458 [INFO ] o.a.j.s.SendMailHandler - Successfully spooled mail 
Mail1595914206122-99a764fb-1097-4614-a1c2-022d0b331bee from 
MaybeSender{mailAddress=Optional[user01@test.local]} on 
localhost/0:0:0:0:0:0:0:1 for [user01@test.local]
14:30:34.797 [INFO ] o.a.j.p.n.BasicChannelUpstreamHandler - Connection closed 
for 0:0:0:0:0:0:0:1
14:31:44.887 [ERROR] o.a.j.t.m.j.d.SieveExecutor - Cannot evaluate Sieve script 
for user 
org.apache.openjpa.persistence.ArgumentException: There is no query with the 
name "findActiveByUsername" defined for any of the known persistent classes: 
[org.apache.james.mailbox.jpa.quota.model.MaxGlobalMessageCount, 
org.apache.james.mailbox.jpa.mail.model.JPAUserFlag, 
org.apache.james.mailbox.jpa.quota.model.MaxUserStorage, 
org.apache.james.mailbox.jpa.mail.model.openjpa.AbstractJPAMailboxMessage, 
org.apache.james.mailbox.jpa.quota.model.JpaCurrentQuota, 
org.apache.james.mailbox.jpa.user.model.JPASubscription, 
org.apache.james.rrt.jpa.model.JPARecipientRewrite, 
org.apache.james.mailbox.jpa.mail.model.JPAMailboxAnnotation, 
org.apache.james.mailbox.jpa.quota.model.MaxDomainMessageCount, 
org.apache.james.mailbox.jpa.quota.model.MaxGlobalStorage, 
org.apache.james.mailbox.jpa.mail.model.JPAMailboxAnnotationId, 
org.apache.james.mailbox.jpa.mail.model.JPAMailbox, 
org.apache.james.mailrepository.jpa.JPAUrl, 
org.apache.james.mailbox.jpa.quota.model.MaxDomainStorage, 
org.apache.james.mailbox.jpa.quota.model.MaxUserMessageCount, 
org.apache.james.domainlist.jpa.model.JPADomain, 
org.apache.james.user.jpa.model.JPAUser, 
org.apache.james.mailbox.jpa.mail.model.JPAProperty, 
org.apache.james.mailbox.jpa.mail.model.openjpa.JPAMailboxMessage].
at 
org.apache.openjpa.meta.MetaDataRepository.getQueryMetaDataInternal(MetaDataRepository.java:1982)
at 
org.apache.openjpa.meta.MetaDataRepository.getQueryMetaData(MetaDataRepository.java:1963)
at 
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:1200)
at 
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:1191)
at 
org.apache.james.sieve.jpa.JPASieveRepository.findActiveSieveScript(JPASieveRepository.java:153)
at 
org.apache.james.sieve.jpa.JPASieveRepository.lambda$findActiveSieveScript$6(JPASieveRepository.java:147)
at 
com.github.fge.lambdas.functions.FunctionChainer.lambda$sneakyThrow$49(FunctionChainer.java:74)
at 
org.apache.james.backends.jpa.TransactionRunner.runAndRetrieveResult(TransactionRunner.java:65)
at 
org.apache.james.sieve.jpa.JPASieveRepository.findActiveSieveScript(JPASieveRepository.java:146)
at 
org.apache.james.sieve.jpa.JPASieveRepository.getActivationDateForActiveScript(JPASieveRepository.java:133)
at 
org.apache.james.transport.mailets.jsieve.ResourceLocator.get(ResourceLocator.java:66)
at 
org.apache.james.transport.mailets.jsieve.delivery.SieveExecutor.sieveMessage(SieveExecutor.java:127)
at 
org.apache.james.transport.mailets.jsieve.delivery.SieveExecutor.execute(SieveExecutor.java:122)
at org.apache.james.transport.mailets.Sieve.service(Sieve.java:75)


Any hints?

Thank you!
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3346) Configure Lucene

[David Leangen (Jira)]

David Leangen created JAMES-3346:


 Summary: Configure Lucene
 Key: JAMES-3346
 URL: https://issues.apache.org/jira/browse/JAMES-3346
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


Lucene files are being stored in the root directory. The should be configured 
to be placed in a location that could be made into a volume.



--
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-3345) Cannot control location of derby.log file

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166093#comment-17166093
 ] 

David Leangen commented on JAMES-3345:
--

The property [appears to 
be|http://db.apache.org/derby/docs/10.8/ref/crefproper22250.html] 
derby.stream.error.file=logs/derby.log. However, when I place this value in the 
james-database.properties file, it has no effect. (Note that the docs are for 
an older version, and I was not able to find that property in the current 
version of the docs.)

Does Derby allow this to be configured? (See also: 
https://stackoverflow.com/questions/1004327/getting-rid-of-derby-log)

If it does, how does James pass along the configuration value?

> Cannot control location of derby.log file
> -
>
> Key: JAMES-3345
> URL: https://issues.apache.org/jira/browse/JAMES-3345
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> I am not able to control the location of the derby.log file. It should be 
> possible to control the location so that all logs can potentially be placed 
> nicely on a logging volume.



--
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] [Created] (JAMES-3345) Cannot control location of derby.log file

[David Leangen (Jira)]

David Leangen created JAMES-3345:


 Summary: Cannot control location of derby.log file
 Key: JAMES-3345
 URL: https://issues.apache.org/jira/browse/JAMES-3345
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


I am not able to control the location of the derby.log file. It should be 
possible to control the location so that all logs can potentially be placed 
nicely on a logging volume.



--
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-3246) Clarify DB Configuration (james-database.properties & META-INF/persistence.xml)

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166087#comment-17166087
 ] 

David Leangen commented on JAMES-3246:
--

Regardless of how we move forward, there is a derby.log file that is not being 
saved in a location that is useful when creating volumes. I am trying to figure 
out how to configure Derby to put this file in a "logs" directory so all the 
log files can potentially be placed on a volume.

> Clarify DB Configuration (james-database.properties & 
> META-INF/persistence.xml)
> ---
>
> Key: JAMES-3246
> URL: https://issues.apache.org/jira/browse/JAMES-3246
> Project: James Server
>  Issue Type: Sub-task
>Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3245) Clarify Sieve Configuration (managesieveserver.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3245.


> Clarify Sieve Configuration (managesieveserver.xml)
> ---
>
> Key: JAMES-3245
> URL: https://issues.apache.org/jira/browse/JAMES-3245
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3243) Clarify HealthCheck Configuration (healthcheck.properties)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3243.


> Clarify HealthCheck Configuration (healthcheck.properties)
> --
>
> Key: JAMES-3243
> URL: https://issues.apache.org/jira/browse/JAMES-3243
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3244) Clarify Listeners Configuration (listeners.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3244.


> Clarify Listeners Configuration (listeners.xml)
> ---
>
> Key: JAMES-3244
> URL: https://issues.apache.org/jira/browse/JAMES-3244
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3239) Clarify Logging Configuration (logback.xml & log4j.properties)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3239.


> Clarify Logging Configuration (logback.xml & log4j.properties)
> --
>
> Key: JAMES-3239
> URL: https://issues.apache.org/jira/browse/JAMES-3239
> Project: James Server
>  Issue Type: Sub-task
>    Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3241) Clarify Extension Configuration (extensions.properties)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3241.


> Clarify Extension Configuration (extensions.properties)
> ---
>
> Key: JAMES-3241
> URL: https://issues.apache.org/jira/browse/JAMES-3241
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3242) Clarify JWT Configuration (jwt_publickey)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3242.


> Clarify JWT Configuration (jwt_publickey)
> -
>
> Key: JAMES-3242
> URL: https://issues.apache.org/jira/browse/JAMES-3242
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3235) Clarify Recipient Rewrite Table Configuration (recipientrewritetable.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3235.


> Clarify Recipient Rewrite Table Configuration (recipientrewritetable.xml)
> -
>
> Key: JAMES-3235
> URL: https://issues.apache.org/jira/browse/JAMES-3235
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3237) Clarify Users Configuration (usersrepository.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3237.


> Clarify Users Configuration (usersrepository.xml)
> -
>
> Key: JAMES-3237
> URL: https://issues.apache.org/jira/browse/JAMES-3237
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3234) Clarify POP3 Configuration (pop3server.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3234.


> Clarify POP3 Configuration (pop3server.xml)
> ---
>
> Key: JAMES-3234
> URL: https://issues.apache.org/jira/browse/JAMES-3234
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Reopened] (JAMES-3233) Simplify Mailet Container Configuration (mailetcontainer.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen reopened JAMES-3233:
--

As discussed in this issue, the configuration is probably needed, but ought to 
be simplified in the context of the Basic Server.

So I am reopening this discussion (with updated title).

> Simplify Mailet Container Configuration (mailetcontainer.xml)
> -
>
> Key: JAMES-3233
> URL: https://issues.apache.org/jira/browse/JAMES-3233
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Updated] (JAMES-3233) Simplify Mailet Container Configuration (mailetcontainer.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen updated JAMES-3233:
-
Summary: Simplify Mailet Container Configuration (mailetcontainer.xml)  
(was: Clarify Mailet Container Configuration (mailetcontainer.xml))

> Simplify Mailet Container Configuration (mailetcontainer.xml)
> -
>
> Key: JAMES-3233
> URL: https://issues.apache.org/jira/browse/JAMES-3233
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3232) Clarify Mail Repository Stores Configuration (mailrepositorystore.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3232.


> Clarify Mail Repository Stores Configuration (mailrepositorystore.xml)
> --
>
> Key: JAMES-3232
> URL: https://issues.apache.org/jira/browse/JAMES-3232
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3231) Clarify LMTP Configuration (lmtpserver.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3231.


> Clarify LMTP Configuration (lmtpserver.xml)
> ---
>
> Key: JAMES-3231
> URL: https://issues.apache.org/jira/browse/JAMES-3231
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Closed] (JAMES-3230) Clarify JMAP Configuration (jmap.properties)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3230.


> Clarify JMAP Configuration (jmap.properties)
> 
>
> Key: JAMES-3230
> URL: https://issues.apache.org/jira/browse/JAMES-3230
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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] [Reopened] (JAMES-3215) Update SSL support in James

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen reopened JAMES-3215:
--

The original issue was "Remove SSL support in James", which we agreed not to 
do. However, this issue still contains a valid description regarding "Update 
SSL support in James".

I am reopening so we can continue this discussion.

> Update SSL support in James
> ---
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> SSL support is not working [1], and it complicates the installation process. 
> It causes the inclusion of various libraries, and Java suucks for SSL 
> support.
> It would make James a lot simpler to remove SSL support and make SSL 
> termination somebody else's problem. These days it should be easy to use a 
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL 
> termination.
> It would be one less thing to maintain in James, one less thing that can go 
> wrong, one less step to take just to get a James server working, and a step 
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the 
> instructions but it still does not work as intended.
> {quote}



--
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] [Updated] (JAMES-3215) Update SSL support in James

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen updated JAMES-3215:
-
Summary: Update SSL support in James  (was: Remove SSL support in James)

> Update SSL support in James
> ---
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
>  Issue Type: Improvement
>        Reporter: David Leangen
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> SSL support is not working [1], and it complicates the installation process. 
> It causes the inclusion of various libraries, and Java suucks for SSL 
> support.
> It would make James a lot simpler to remove SSL support and make SSL 
> termination somebody else's problem. These days it should be easy to use a 
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL 
> termination.
> It would be one less thing to maintain in James, one less thing that can go 
> wrong, one less step to take just to get a James server working, and a step 
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the 
> instructions but it still does not work as intended.
> {quote}



--
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] [Created] (JAMES-3341) Clarify DB Configuration (james-database.properties)

[David Leangen (Jira)]

David Leangen created JAMES-3341:


 Summary: Clarify DB Configuration (james-database.properties)
 Key: JAMES-3341
 URL: https://issues.apache.org/jira/browse/JAMES-3341
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3246]



--
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] [Created] (JAMES-3340) Clarify Sieve Configuration (managesieveserver.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3340:


 Summary: Clarify Sieve Configuration (managesieveserver.xml)
 Key: JAMES-3340
 URL: https://issues.apache.org/jira/browse/JAMES-3340
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3245]



--
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] [Created] (JAMES-3339) Clarify Listeners Configuration (listeners.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3339:


 Summary: Clarify Listeners Configuration (listeners.xml)
 Key: JAMES-3339
 URL: https://issues.apache.org/jira/browse/JAMES-3339
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3244]



--
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] [Created] (JAMES-3337) Clarify JWT Configuration (jwt_publickey)

[David Leangen (Jira)]

David Leangen created JAMES-3337:


 Summary: Clarify JWT Configuration (jwt_publickey)
 Key: JAMES-3337
 URL: https://issues.apache.org/jira/browse/JAMES-3337
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3242]



--
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] [Created] (JAMES-3338) Clarify HealthCheck Configuration (healthcheck.properties)

[David Leangen (Jira)]

David Leangen created JAMES-3338:


 Summary: Clarify HealthCheck Configuration (healthcheck.properties)
 Key: JAMES-3338
 URL: https://issues.apache.org/jira/browse/JAMES-3338
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3243]



--
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] [Created] (JAMES-3336) Clarify Extension Configuration (extensions.properties)

[David Leangen (Jira)]

David Leangen created JAMES-3336:


 Summary: Clarify Extension Configuration (extensions.properties)
 Key: JAMES-3336
 URL: https://issues.apache.org/jira/browse/JAMES-3336
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3241]



--
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] [Created] (JAMES-3334) Clarify Logging Configuration (logback.xml & log4j.properties)

[David Leangen (Jira)]

David Leangen created JAMES-3334:


 Summary: Clarify Logging Configuration (logback.xml & 
log4j.properties)
 Key: JAMES-3334
 URL: https://issues.apache.org/jira/browse/JAMES-3334
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3239]



--
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] [Created] (JAMES-3335) Clarify JMX Configuration (jmx.properties)

[David Leangen (Jira)]

David Leangen created JAMES-3335:


 Summary: Clarify JMX Configuration (jmx.properties)
 Key: JAMES-3335
 URL: https://issues.apache.org/jira/browse/JAMES-3335
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3240]



--
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] [Created] (JAMES-3333) Clarify WebAdmin Configuration (webadmin.properties)

[David Leangen (Jira)]

David Leangen created JAMES-:


 Summary: Clarify WebAdmin Configuration (webadmin.properties)
 Key: JAMES-
 URL: https://issues.apache.org/jira/browse/JAMES-
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3238]



--
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] [Created] (JAMES-3331) Clarify SMTP Configuration (smtpserver.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3331:


 Summary: Clarify SMTP Configuration (smtpserver.xml)
 Key: JAMES-3331
 URL: https://issues.apache.org/jira/browse/JAMES-3331
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3236]



--
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] [Created] (JAMES-3332) Clarify Users Configuration (usersrepository.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3332:


 Summary: Clarify Users Configuration (usersrepository.xml)
 Key: JAMES-3332
 URL: https://issues.apache.org/jira/browse/JAMES-3332
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3237]



--
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] [Created] (JAMES-3330) Clarify Recipient Rewrite Table Configuration (recipientrewritetable.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3330:


 Summary: Clarify Recipient Rewrite Table Configuration 
(recipientrewritetable.xml)
 Key: JAMES-3330
 URL: https://issues.apache.org/jira/browse/JAMES-3330
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3235]



--
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] [Created] (JAMES-3329) Clarify POP3 Configuration (pop3server.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3329:


 Summary: Clarify POP3 Configuration (pop3server.xml)
 Key: JAMES-3329
 URL: https://issues.apache.org/jira/browse/JAMES-3329
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3234]



--
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] [Created] (JAMES-3328) Clarify Mailet Container Configuration (mailetcontainer.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3328:


 Summary: Clarify Mailet Container Configuration 
(mailetcontainer.xml)
 Key: JAMES-3328
 URL: https://issues.apache.org/jira/browse/JAMES-3328
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3233]



--
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] [Created] (JAMES-3327) Clarify Mail Repository Stores Configuration (mailrepositorystore.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3327:


 Summary: Clarify Mail Repository Stores Configuration 
(mailrepositorystore.xml)
 Key: JAMES-3327
 URL: https://issues.apache.org/jira/browse/JAMES-3327
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3232]



--
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] [Created] (JAMES-3326) Clarify LMTP Configuration (lmtpserver.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3326:


 Summary: Clarify LMTP Configuration (lmtpserver.xml)
 Key: JAMES-3326
 URL: https://issues.apache.org/jira/browse/JAMES-3326
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3231]



--
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] [Created] (JAMES-3325) Clarify JMAP Configuration (jmap.properties)

[David Leangen (Jira)]

David Leangen created JAMES-3325:


 Summary: Clarify JMAP Configuration (jmap.properties)
 Key: JAMES-3325
 URL: https://issues.apache.org/jira/browse/JAMES-3325
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3230]



--
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] [Created] (JAMES-3324) Clarify IMAP Configuration (imapserver.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3324:


 Summary: Clarify IMAP Configuration (imapserver.xml)
 Key: JAMES-3324
 URL: https://issues.apache.org/jira/browse/JAMES-3324
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3229]



--
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] [Created] (JAMES-3323) Clarify DomainList Configuration (domainlist.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3323:


 Summary: Clarify DomainList Configuration (domainlist.xml)
 Key: JAMES-3323
 URL: https://issues.apache.org/jira/browse/JAMES-3323
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3220]



--
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] [Created] (JAMES-3322) Clarify DNS configuration (dnsservice.xml)

[David Leangen (Jira)]

David Leangen created JAMES-3322:


 Summary: Clarify DNS configuration (dnsservice.xml)
 Key: JAMES-3322
 URL: https://issues.apache.org/jira/browse/JAMES-3322
 Project: James Server
  Issue Type: Sub-task
Reporter: David Leangen


See [JAMES-3219] for more information.



--
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] [Updated] (JAMES-3321) Makes James Extendable Server easier to use

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen updated JAMES-3321:
-
Description: 
The "James Extendable Server" is currently described as:

h2. James Extendable Mail Server

 
 When your requirements start to get a little more serious, or you start to 
feel adventurous and want to begin your own email adventure, you can consider 
using the *Extendable Server*.

This server is intended for experts who understand the consequences of what 
they are doing. It provides extension mechanisms, configurations, and 
integration points to customize its behavior. Unless you are processing 
millions of emails on a daily basis (in which case you should consider the 
[Distributed Server|#distributed]), this server should cover just about any 
email needs you may have.

 
 This server is currently difficult to set up and use.

To make James more appealing to new users, installation should be simplified. 
When input or configuration is required by users, it should be minimized and 
well documented.

 

> Makes James Extendable Server easier to use
> ---
>
> Key: JAMES-3321
> URL: https://issues.apache.org/jira/browse/JAMES-3321
> Project: James Server
>  Issue Type: Improvement
>    Reporter: David Leangen
>Priority: Major
>
> The "James Extendable Server" is currently described as:
> 
> h2. James Extendable Mail Server
>  
>  When your requirements start to get a little more serious, or you start to 
> feel adventurous and want to begin your own email adventure, you can consider 
> using the *Extendable Server*.
> This server is intended for experts who understand the consequences of what 
> they are doing. It provides extension mechanisms, configurations, and 
> integration points to customize its behavior. Unless you are processing 
> millions of emails on a daily basis (in which case you should consider the 
> [Distributed Server|#distributed]), this server should cover just about any 
> email needs you may have.
> 
>  
>  This server is currently difficult to set up and use.
> To make James more appealing to new users, installation should be simplified. 
> When input or configuration is required by users, it should be minimized and 
> well documented.
>  



--
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] [Created] (JAMES-3321) Makes James Extendable Server easier to use

[David Leangen (Jira)]

David Leangen created JAMES-3321:


 Summary: Makes James Extendable Server easier to use
 Key: JAMES-3321
 URL: https://issues.apache.org/jira/browse/JAMES-3321
 Project: James Server
  Issue Type: Improvement
Reporter: David Leangen






--
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] [Closed] (JAMES-3220) Clarify DomainList Configuration (domainlist.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3220.


> Clarify DomainList Configuration (domainlist.xml)
> -
>
> Key: JAMES-3220
> URL: https://issues.apache.org/jira/browse/JAMES-3220
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> As part of the Basic James Server, there is a domainlist.xml configuration. 
> Not all aspects of this are clear, and perhaps there are some simplifications 
> that could be made.



--
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] [Closed] (JAMES-3219) Clarify DNS configuration (dnsservice.xml)

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3219.


> Clarify DNS configuration (dnsservice.xml)
> --
>
> Key: JAMES-3219
> URL: https://issues.apache.org/jira/browse/JAMES-3219
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> I would like to provide a little more detailed documentation for the DNS 
> service, since users are required to configure this service (or use the 
> default config) in order to run the James Basic Server.



--
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] [Closed] (JAMES-3218) Specify "User" and "Use" of a James Server

[David Leangen (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed JAMES-3218.


> Specify "User" and "Use" of a James Server
> --
>
> Key: JAMES-3218
> URL: https://issues.apache.org/jira/browse/JAMES-3218
> Project: James Server
>  Issue Type: Sub-task
>Reporter: David Leangen
>Priority: Major
>
> The level of support provided depends on how "User" and "Use" is defined.
> See: [https://www.mail-archive.com/server-dev@james.apache.org/msg66344.html]



--
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

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

> Some of the topics in the last few days:
> - how to run the SMTP server
> - how to process the emails
> - how to configure James

I think if we stick to the concept of Basic Server and Extendable Server, those 
use cases will naturally be taken care of. I explain more below.


> I prefer documenting manually each mailet/matcher individually so far,
> based on the existing javadoc.

This is also required for the Extendable Server, so I will help out here.



The original plan was:

 * Get the Basic Server working and document it
 * Get the Extendable Server working and document it

My assumption is:

 * The Distributed Server should describe most of the same concepts as the 
Extendable Server, except
 —> It needs to talk about distributed concepts (Cassandra etc.)

I have been using the project that Eugen set up:

—> https://github.com/ieugen/james-self-hosting-sandbox/

Also thanks to Eugen’s work with gradle, I am able to compile the code and 
actually run it in debug mode in IntelliJ.

I am making progress, but it is very slow progress, partly because I am new to 
IntelliJ, but mostly because I keep running into road blocks. For instance, 
right now I am trying to figure out how persistence works so I can save state 
between executions. It is not at all obvious to me yet why the data resets each 
time. Then I need to figure out why I’m not able to authenticate when I start 
an SMTP session, but determining that is also not obvious, so I am trying to 
step through the code to understand what is happening.

This is just one issue. I keep hitting wall after wall after wall. As a newbie 
and without a clear path, it takes me a lot of time to figure these things out. 
The advantage, though, is that it gives me the material I need to write the 
docs, and the suggestions for how the Basic and Extendable Servers ought to 
work.

If it were possible to get more help getting the Basic Server and Extendable 
Server working, I could make much faster progress with the docs, and we would 
have better answers for the users that ask the questions that Eugen was 
pointing out. :-)


Cheers,
=David



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

> It's great to see progress on this.

Yes indeed!

> Do you think it's possible to push for a website ready for review by 1st 
> august?

For me at least, this is too ambitious. Perhaps a few more (say, weekly?) 
milestones and a final review by the end of August?

At least from my perspective, there is still lots and lots of work to do. 
Personally, I think we should have an initially working site, rather than 
something half-baked.

But then, maybe we haven’t yet completely clarified the objective(s) of the 
site?? It could very well be that you have different objectives from me.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

>> I will need a bit more time.
> Take it :-)

I will reply directly in the code by means of a PR (either by making changes to 
the code that we can revise before merging or by adding comments).

Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

> For Mailet/Matchers, I would port existing documentation from javadoc to 
> antora (and use includes to not duplicate the sources).

Do you mean transform from Javadoc format to asciidoc format (either manually 
or with a conversation tool)?

Or do you mean build a tool to extract the Javadoc and transform it to asciidoc?


> JavaDoc would be more for targeting "developers" and is a nice to have too. 
> Especially for API projects (mailet-api, mailbox-api, mailqueue-api, etc...) 
> where Javadoc is both maintained and valuable.

If somebody can integrate the javadoc into the build (if it isn’t already), 
then I can look into integrating the javadocs into Antora.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

>>> Cool! I will try to take some time today to comment more thoroughly, likely 
>>> in the form of a PR.

>> There is quite a lot of text there and a lot of concepts, so it will take me 
>> a while to go through it. :-)

> Maybe more importantly than going through the entire text, the important
> question for me would be:
> 
>  - Which concepts do you miss to understand this doc?

I will need a bit more time.

>  - Can we address that with a better structure?

Ok, if I take a very quick top-down view, here are my immediate comments, 
though I don’t know how useful they are. 

I notice that effectively you mention:

 * Running
 * Configuring
 * Operating
 * Extending

From our User Model, we have:

• User —> Probably not relevant
• Operator —> Relevant
• Integrator —> Relevant
• Developer —> 
• Contributor —> 
• Committer —> 
• PMC Member —> Probably not relevant

What were your thoughts regarding the target audience of these docs? Was it 
your intention that:

 * Running —> Operator??
 * Configuring —> Operator??
 * Operating —> Operator (this one is clear)
 * Extending —> Integrator (this one is clear, too)

Or did you have some other structure in mind? It’s difficult for me to grasp 
exactly what you are intending.

I would have thought that “Operating” includes Installing, Configuring, 
Running. An Operator (as we define in the User Model) would naturally go to the 
“Operating” section to figure out how to Operate the server.


Like I said, those are just my initial gut reactions. I’ll try to dig in more 
next week.


> I'm really looking forward into this review ;-)

Whew, pressure! Hope I don’t disappoint. 


> Also note that I did not merge yet the most recent works and
> improvements for the Distributed Server doc... Do you want me to merge
> it before your review, to make it easier for you?

Please, yes! Thank you.

Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

> Cool! I will try to take some time today to comment more thoroughly, likely 
> in the form of a PR.

There is quite a lot of text there and a lot of concepts, so it will take me a 
while to go through it. :-)


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Antora documentation: thoughts about mailetdoc-maven-plugin and Antora includes

[David Leangen]

Hi Benoit,

Thank you for giving this so much thought.

(By the way, I am very sorry that I have been less available these days, and 
will continue to be so for the next few weeks, but I will still try to 
contribute to this as much as possible.)

> I am making good progress on Antora documentation migration for the
> Distributed Server, only a couple of pages are left.

Cool! I will try to take some time today to comment more thoroughly, likely in 
the form of a PR.


> [...] I propose to retire the maven-doc plugin, and migrate the
> javadoc that exist today as Antora Documentation.

I am happy to spend time looking into integrating with Javadoc. I recall 
reading in the Antora manual that since it reads from the git repository, we 
can insert actual code snippets and javadoc into the documentation. I remember 
this because I thought it was a very cool feature. However, I have not yet 
looked into it in any detail so I can’t say any more at this time. If I can, I 
will try to take a look today.



> Also, now that I almost finished the Distributed server documentation, I
> start thinking of my next step: documenting the other servers.

There is already a PR outstanding for the Basic Server, but it is still in 
draft mode because I am not yet done:

  —> https://github.com/apache/james-project/pull/206


Regarding the Extendable Server, I am currently trying to run it and use it so 
I can understand it. I have managed to get the system compiling and can finally 
run in debug mode in IntelliJ, but because I have never used this IDE before, 
my progress is slow.  I have filed a few issues to help me make progress. 
Maybe I’ll bump those since it is easy for them to get lost (or if you have a 
suggestion for a better way for me to communicate my issues, I will follow your 
suggestion).

Once I can understand the Extendable Server better, I am planning on writing 
about it.


Of course, the concepts for these servers are based on what is in the 
“Concepts” section, which still has many, many holes.


> I believe we should keep documentation writing centralize to ease its 
> maintenance
> while keeping each server documentation complete for the reader path to
> be straightforward.

I am not quite sure I understand what you mean by this point.

Regarding Antora includes and such, yes you are right: we should definitely use 
these when appropriate.

I am also happy that you are thinking about this from the reader’s perspective. 
We also have to remember that “reader” can be one of: 

• User
• Operator
• Integrator
• Developer

and the docs should be geared toward whichever role the reader happens to be 
playing.



Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Which repositories are we using and going to document? Let's retire the ones we don't

[David Leangen]

>> While working on the documentation website

I have been distracted by other work the past 2 weeks. I hope to get back to 
this project within this week.

Thanks for helping to push it forward!


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.5.0

[David Leangen]

> I would like to propose a new vote 3.5.0 release of the Apache James server.

+1


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Consensus needed: replace james-site master branch with live branh - reset

[David Leangen]

Hi,

>> If no objections are received in the next 3 days I'll move forward with
>> the change.

Thanks for all your efforts. Sorry that I have not moved forward much in the 
past days. I have been preoccupied with other things.

I am having trouble imagining what you are referring to exactly in your 
description. It would be very useful for me to see some kind of visual 
representation of how you are intending to organize the site. I was thinking 
that the current top page is pretty nice, so maybe it could be reworked, then 
the docs would somehow fit into that.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156414#comment-17156414
 ] 

David Leangen commented on JAMES-3226:
--

Hi [~ieugen], do you think we could discuss the site structure with some kind 
of visual mock-up? I'm having trouble visualizing what you are trying to do. 
Thanks!

> Provide a process around documentation publishing and deployment
> 
>
> Key: JAMES-3226
> URL: https://issues.apache.org/jira/browse/JAMES-3226
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> We have started working on the documentation and it's great.
> We should also document the processes around documentation:
> - when we publish the docs
> - how to publish the docs
> - where to publish the docs
> - when we retire old docs ?!
> This task should aggregate discussion and decisions.
> The process should be written as asciidoc.
> We decided to use antora as a documentation system so the features are going 
> to depend on that technology. 
> We should have documentation for every release we make. 
> This is important since  people don't upgrade immediately after release and 
> might use an older release for some time.
> I'm not sure if the documentation for all versions should be online.
> We can build zip archives of each documentation release and include it in the 
> binary release  or publish them for download next to it. 
> This way we can keep only the latest 1-3 versions online.



--
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] [Created] (JAMES-3304) No diagnostics for failed authorization

[David Leangen (Jira)]

David Leangen created JAMES-3304:


 Summary: No diagnostics for failed authorization
 Key: JAMES-3304
 URL: https://issues.apache.org/jira/browse/JAMES-3304
 Project: James Server
  Issue Type: Bug
Reporter: David Leangen


When attempting to test a running James server, I attempted to manually 
authenticate a user.

I received an error in the SMTP session: 
{code:java}
535 Authentication Failed{code}
This is fine within the session, but there is no diagnostic information 
anywhere in James to help me figure out what is going wrong.

Is there a simple way to log, or something, so I can diagnose what is happening 
during the SMTP session?



--
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] [Created] (JAMES-3303) Can add domain even when virtualhosting disabled

[David Leangen (Jira)]

David Leangen created JAMES-3303:


 Summary: Can add domain even when virtualhosting disabled
 Key: JAMES-3303
 URL: https://issues.apache.org/jira/browse/JAMES-3303
 Project: James Server
  Issue Type: Bug
Reporter: David Leangen


I happened to notice that it is possible to add a domain even if virtual 
hosting is not enabled.

 

Steps:
 # Add a domain
 # Attempt to add a user
 # Receive an error:

 
{code:java}
Error class java.lang.Exception while executing command:Given Username contains 
a @domainpart but virtualhosting support is disabled{code}
 

Is there a purpose for allowing the addition (or even the management) of 
domains if virtual hosting is not enabled?



--
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-3301) Create old site inventory

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155013#comment-17155013
 ] 

David Leangen commented on JAMES-3301:
--

Very nice to have the inventory. Thanks!

IMO, I think it is great to have a checklist to make sure we aren't missing 
anything in the new docs. I am sure there are some nice gems in there. However, 
I'm not really sure that we want to migrate any content "as is".

Perhaps we could have a "legacy" section that is more aimed to those already 
familiar with James? Just a thought.

> Create old site inventory 
> --
>
> Key: JAMES-3301
> URL: https://issues.apache.org/jira/browse/JAMES-3301
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> Before we move forward with the site we need to build an inventory of what we 
> have.
>  
> We seem to have, in james-project the following:
>  
> {noformat}
> tree -d src/ 
> src/
> ├── adr
> ├── homepage
> │   ├── assets
> │   │   ├── css
> │   │   │   └── images
> │   │   ├── fonts
> │   │   ├── images
> │   │   └── js
> │   │   └── ie
> │   ├── howTo
> │   ├── images
> │   ├── _includes
> │   ├── _layouts
> │   └── _posts
> ├── reporting-site
> └── site
> ├── apt
> │   ├── mailet
> │   │   └── examples
> │   └── mpt
> ├── custom
> ├── markdown
> │   ├── mailet
> │   └── server
> │   └── install
> ├── resources
> │   ├── css
> │   ├── downloads
> │   ├── images
> │   ├── js
> │   │   └── james
> │   ├── mailbox
> │   │   └── images
> │   │   └── uml
> │   ├── mailet
> │   │   └── css
> │   ├── model-eclipse-modeler
> │   ├── protocols
> │   │   └── images
> │   │   └── uml
> │   └── server
> │   ├── css
> │   ├── images
> │   │   ├── conf
> │   │   ├── database
> │   │   ├── dns-mx
> │   │   ├── eclipse
> │   │   ├── intellij-idea
> │   │   ├── jmx-management
> │   │   ├── jmx-monitoring
> │   │   ├── netbeans
> │   │   ├── performances
> │   │   └── uml
> │   ├── js
> │   └── rfclist
> │   ├── basic
> │   ├── imap4
> │   ├── ldap
> │   ├── lmtp
> │   ├── pop3
> │   └── smtp
> └── xdoc
> ├── mailbox
> ├── mailet
> │   ├── ai
> │   ├── api
> │   ├── base
> │   ├── crypto
> │   ├── mailetdocs-maven-plugin
> │   ├── standard
> │   └── stylesheets
> ├── mpt
> ├── protocols
> └── server
> └── archive75 directories
> {noformat}
>  
>  
> The content is in the following formats:
>  * markdown
>  * xdoc
>  * apt ?!
> *We also have javadocs*
> Gradle has out of the box support for Javadoc.
> It's a matter of configuration and also aggregating them for publication.
>  
>  
>  



--
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-3302) Migrate old site pages to asciidoc

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155012#comment-17155012
 ] 

David Leangen commented on JAMES-3302:
--

Personally, I wouldn't spend too much time on this. It does have some value, 
but your efforts would probably be better spent elsewhere IMO.

> Migrate old site pages to asciidoc
> --
>
> Key: JAMES-3302
> URL: https://issues.apache.org/jira/browse/JAMES-3302
> Project: James Server
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> Once we have the inventory we should migrate the old content to Antora / 
> Asciidoc.
> For most formats we could do an automated migration.
> We might not migrate all components.
> We will not migrate obsolete content.



--
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

Re: Building Antora documentation

[David Leangen]

Hi Eugen,

Thank you very much for all your efforts. The community is fortunate that you 
are able to dedicate so much concentrated effort.

> I've given up on building the old site since I failed several times.

I think that’s ok, though. Honestly, I don’t see a viable path forward in terms 
of “migrating” the old docs. Yes, there is some good information still in those 
docs, and some good stuff that could inspire the new docs, however, I think the 
only practical way forward is to start over, from a top-down perspective. IMO, 
we need to make a clean break, and at the same time re-evaluate the James 
mission. (But that’s just my opinion and I’m just a newbie so my voice doesn’t 
hold as much weight.)

I like the inventory. I can use that as a checklist to make sure the new docs 
aren’t leaving anything out. Or maybe the old docs could be assembled for the 
“developer” part of the site, aimed at experienced James developers who already 
know their way around and just need a reference. But I don’t see how the 
current docs could be useful for Operators or Integrators who don’t have 
experience with James.

So with that in mind...

> I've create two issues to track the progress of migrating the old site
> to Antora.
> 
> * Make an inventory of old site
> https://issues.apache.org/jira/browse/JAMES-3301

Cool, thanks! I think this can be useful.

> * Migrate the content https://issues.apache.org/jira/browse/JAMES-3302
> 
> Please help out with the inventory and if you have ideas with the content.
> 
> I'll migrate what I can, we can sort them after.

I don’t think that’s necessary, but if it’s already done, then great.


Thanks again!
=David




signature.asc
Description: Message signed with OpenPGP

[jira] [Commented] (JAMES-3236) Clarify SMTP Configuration (smtpserver.xml)

[David Leangen (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154212#comment-17154212
 ] 

David Leangen commented on JAMES-3236:
--

[~btellier], if you have the time, can you (or anybody) help me here?

> Clarify SMTP Configuration (smtpserver.xml)
> ---
>
> Key: JAMES-3236
> URL: https://issues.apache.org/jira/browse/JAMES-3236
> Project: James Server
>  Issue Type: Sub-task
>        Reporter: David Leangen
>Priority: Major
>
> In the context of the *Basic Server*, determine if (1) this configuration is 
> necessary, and if so (2) how can we minimize it and (3) document it better.



--
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

Re: SMTP Relay (Was: Queuing vs. spooling)

[David Leangen]

Hi Eugen,

Thanks for your support.

> GIven the discussion around the specific topics I think we are getting
> our documentation.
> @David: If you can do just that: ask questions and compile the answers
> it would be a huge win for us.

Thanks, that is indeed the intent since the beginning. The ability to move 
forward depends on how much everybody participates in answering my (often 
stupid) questions.

I am approaching this from a newbie’s perspective, simply because I am one. As 
I mentioned in the beginning, (although less and less so now) I have the 
“advantage” of knowing very little about how James works, so it is easier for 
me to imagine what it’s like for other newbies trying to learn James, and what 
needs to be done to help make James more usable and thus more popular.

It does require time and patience from everybody though. I hope the efforts 
will turn out to be worthwhile.

Thanks for all the help so far. Please keep it coming!!


Cheers,
=David




signature.asc
Description: Message signed with OpenPGP

Re: SMTP Relay (Was: Queuing vs. spooling)

[David Leangen]

Thanks.

I love this James adventure. It is not boring. Every time I scratch the 
surface, a new concept pops out. 

Ok, so digging in…

> Also as Matthieu said, RemoteDelivery is a side effect of the current 
> Processing chain.

I looked at org.apache.james.transport.mailets.RemoteDelivery, with the 
assumption that it is the correct Mailet.


First, the javadoc says:

> The RemoteDelivery mailet delivers messages to a remote SMTP server able to 
> deliver or forward messages to their final destination.

That is consistent with what you wrote. So I looked at the code to try to get a 
sense of *how* it does this. What I could gather is that the magic is actually 
done with org.apache.james.queue.api.MailQueue. All RemoteDelivery does is 
enqueue the Mail, then it’s done.

So the queue-api seems now quite important. I also gather that it is the same 
queue that accepts mails from the incoming SMTP Service in the figure. However, 
by looking at the api code and the sparse javadocs that come with it, I am 
getting few clues as to what it does or how it works.

I can only guess that the actual heavy lifting is done with an implementation 
that gets wired with Guice.


I will investigate further, but in the meantime, can somebody please point me 
in the right direction to help speed up my journey?


Thanks!
=David




signature.asc
Description: Message signed with OpenPGP

Re: SMTP Relay (Was: Queuing vs. spooling)

[David Leangen]

> The only wrong thing about this picture is the SMTP Service before "Outgoing".

Ok, thank you Matthieu.

> As weird as it is, the delivery of messages to a remote server is done by a 
> Mailet called RemoteDelivery and it's not handled by the SMTP Service.
> As far as I know, a lot of people are actually forking this Mailet because 
> they want specific behaviors for delivery so I think this design makes sense.

Ok sure, but doesn’t that Mailet have to “speak” SMTP? I.e., doesn’t it 
effectively become an SMTP client, that opens a session with a remote SMTP 
server?

Or am I again misunderstanding something fundamental about how SMTP works?


Cheers,
=David



signature.asc
Description: Message signed with OpenPGP

Re: James SMTP Model

[David Leangen]

Sorry, I do have one more question in response to your email…

You wrote:

> In my opinions we should document "How to write hooks with the
> protocols/smtp library", "How to plug such hooks into a running James
> server"
> 
> Then "How to write commands for the protocols/smtp library" (and how to
> plug them in James)

This is starting to make better sense to me now. Thanks for your patience.

Moving on… on this page:

  —> https://james.apache.org/server/feature-smtp-hooks.html


> The James SMTP Server Component allows to easy write your own code which will 
> get executed in the SMTP-Transaction. Thats a bit different then using a 
> Mailet a.k.a Mailet-API.
> 
> To customize your SMTP Server, you have a few interfaces which helps you to 
> "hook-in" a specific SMTP Command. That means your class which implements the 
> given interface(s) will get called after the SMTP-Command was parsed and 
> depending on your implementation it will handle it.
> 
> As your code will get executed before the mail was even accepted. This can 
> help you in many ways, most times its used for rejecting SPAM/Junk within the 
> SMTP-Dialog. But it can be used for other things too.
> 
> Its up to you and your use case.
> 
> But be aware as your code needs to get executed during the SMTP-Transaction 
> it should not take to long to execute. As it will need to fit in before the 
> timeout was hit which can be different on every mail server. But as a general 
> rule as long as your code can get executed within 30 seconds it should be 
> fine.


There is even a list of hooks on this page:

  —> https://james.apache.org/server/dev-provided-smtp-hooks.html


However… Can you provide more examples to help me better understand why I 
should care about these hooks, and why I would want to consider using a hook 
instead of a Mailet? Wouldn’t it be simpler just to have a single extension 
mechanism? What is the value of having two different extension mechanisms?


Thanks!

=David



signature.asc
Description: Message signed with OpenPGP

SMTP Relay (Was: Queuing vs. spooling)

[David Leangen]

Still on the topic of SMTP relay and the original image I posted at the 
beginning of this thread:

 —>  https://james.apache.org/images/james-smtp-relay.png


Would the attached (lousy) image be a reasonable representation of the general 
concept of an SMTP Relay?



signature.asc
Description: Message signed with OpenPGP

Re: James SMTP Model

[David Leangen]

> I gonna try my best, given my time constraints :-)

Thank you!

This is all very good information, which allows me to peel one more layer of 
the onion.

Likely my next batch of questions will be in a separate email thread, as I 
think we have exhausted the concept of “James SMTP Model”.

In the meantime, I have some things to work with so I can push forward a little 
more.


Thanks a lot!

Cheers,
=David




signature.asc
Description: Message signed with OpenPGP