Hello,
Since I am very new to James, I have the advantage of looking at the available
documents with fresh eyes. For that reason, I am currently working on trying to
update the documentation, and have submitted a PR to get the ball rolling. [1]
I will need some help for much of this work. I
Thank you, Matthieu.
>> * Is the name “product” set in stone? Would it be possible to call
>> it a “profile” for example?
>
> I don't really care. I don't really like "product" name. Maybe
> "profile" is better but I'm not sure.
Ok, thank you. So unless somebody raises an objection, I will go
Hello,
As part of my documentation project, I am starting to turn my attention towards
the code itself. I am trying to understand how the system works. I’ll be
honest: it’s not an easy task! I think it ought to be made a lot easier thanks
to some refactoring, but I’ll save that for another
Hi,
Sorry for the barrage of emails, but I hope to get help from the community. I
hope the benefits of what I plan to contribute will be worth the efforts that
you make to answer my questions. Thanks for bearing with me. :-)
I wanted to ask about API boundaries. As I mentioned in a
Hi!
As I just mentioned in a different email:
> As part of my documentation project, I am starting to turn my attention
> towards the code itself. I am trying to understand how the system works. […]
> To understand the system better, I need to take a step back and understand
> Guice. I am
Thank you for the explanations. I now understand much better the migration from
Spring to Guice, and the intent behind Guice.
Instead of directly answering the questions you posed, I will make a proposal
that I think goes in the same direction as your comments.
> This documentation effort
> But maybe all of this should be discussed in a separate thread as a
> "Guice roadmap"…
These all seem like great ideas to me.
I just had a wild thought based on your ideas. Just like there is a concept out
there of “headless CMS”, maybe we could have some concept of a “headless
enterprise
Thank you very much for the reply.
>> Should I even bother learnings about Spring?
>
> No.
Ok, in that case I think it is clear that I should just ignore Spring while
developing the documentation.
Honestly, I think we should just avoid all mention of it all together. All it
will do is
> But maybe all of this should be discussed in a separate thread as a
> "Guice roadmap"…
Good idea to discuss this in a separate thread.
In the meantime, I will continue down the path I mentioned here:
https://www.mail-archive.com/server-dev@james.apache.org/msg65771.html
Hi Matthieu,
Thank you for the great comments! My replies inline.
>> 1. What are these configurations for?
>
> It's related to our product strategy.
[snip]
> a product is a solution that we package and has been tested to work. A user
> can expect the community to care about problems on
Hi!
I am attempting to complete the “Try James in 5 minutes” page for newcomers. I
wanted to show how to connect to the Admin API using curl according to the
instructions on this page [1], but am having trouble doing so myself.
[1] http://james.apache.org/server/manage-webadmin.html
I am
Hi!
For the documentation project, I am trying to get the lay of the land with
regards to the sub-projects and related projects.
My understanding is that this is the list of projects:
• https://github.com/apache/james-project (of course)
• https://github.com/apache/james-mime4j A library
is the
easiest way to customize the configuration as you describe without having to
build a new image?
Cheers,
=David
> On May 14, 2020, at 16:01, Matthieu Baechler wrote:
>
> Hi David,
>
> On Thu, 2020-05-14 at 14:55 +0900, David Leangen wrote:
>> Hi!
>>
>> I am atte
Hi!
I noticed that there is a “util” module that is released as a separate jar.
Given that the size of the jsieve project is so small, is it really necessary
to release it as two separate jar files? Would it be reasonable to consider
folding the “util” module into the “core” module, and to
Hi Benoit,
> I would be carefull: the maven module "util" has a depedency to
> javax.mail, causing some potential dependecy conflicts for users.
I think it’s ok to have optional dependencies. Only those who want to use the
functionality that requires javax.mail would have to provide it at
Hi,
I am having a bit of trouble distinguishing the jsieve API from its
implementation. It is my intention to document this project, but I find it more
difficult to understand than it ought to be because of this problem.
If the library is small enough and the integration simple enough, then
>> If you agree with this approach, then I will create a Jira Issue this time
>> and work against that. :-)
>
> :+1:
Created https://issues.apache.org/jira/browse/JAMES-3188
-
To unsubscribe, e-mail:
Hi Matthieu,
>> I would wager that in most situations, this is the level of abstraction that
>> is most useful for a developer or system operator (and definitely for an
>> application assembler). The only time a package or class level is necessary
>> is when actually making changes to the
it's worth asking him...
>
> Regards,
>
> Raphaël.
>
> Le 14/05/2020 à 08:38, David Leangen a écrit :
>> Hi!
>>
>> For the documentation project, I am trying to get the lay of the land with
>> regards to the sub-projects and related projects.
>>
d.
>
> You can simply use a docker volume on your `docker run` command.
>
> The path inside the container is `/root/conf`.
>
> So `docker run ... -v
> $PWD/webadmin.properties:/root/conf/webadmin.properties ...` should do
> the trick.
>
> Regards,
>
> B
Hello!
While writing the documentation, I came across a term for which I would like to
propose a change. Benoit asked that we hold a discussion here before making a
final decision.
I am proposing that we change “Product” (as in for example the "James with
Guice + Cassandra + RabbitMQ +
> A hexagon defines some ports (the component it needs to work), some adapters
> (the implementations it provides to other hexagons) and a core domain: the
> logic of this hexagon.
Thank you for elaborating your thoughts. I see much better now what you are
trying to do. I like many of the
Hi,
I created the issue: https://issues.apache.org/jira/browse/JAMES-3190
> I was told [1] that James has a hexogonal architecture [2]. However, that is
> not at all apparent neither in the documentation, nor in the code itself.
> If this is truly the fundamental concept of the system design,
Hi!
I am trying to untangle the jsieve API in order to try to document it.
Apparently, a good place to start looks like the org.apache.jsieve.SieveFactory
class because:
> SieveFactory is the primary invocation point for all Sieve operations.
So to start me on this journey: SieveFactory has
Hello,
> If we can reach agreement on a definition for each of these, then we can
> determine (1) how to document the concepts, and (2) if the code should be
> refactored to better reflect these concepts.
Since I am starting to run out of time, I need to press forward. So for now
since I
Thanks for the comments.
>> So I gather than the email must be RFC882 compliant, which means that its
>> implementing class must also be RFC882 compliant. Further, the implementing
>> class must also be RFC5228 compliant. So the email object must effectively
>> be both RFC882 **AND** RFC5882
>> Perhaps provide a “default” MailAdapter? In that case, then the factory
>> could even just take an email and a SieveScript InputStream and apply the
>> default MailAdapter. The method with the MailAdapter signature would only be
>> needed for custom MailAdapters.
>
> JSIEVE (core) don't
>> Thanks Benoit, very helpful! It does lead to more questions, though. :-)
>
> The contrary would have surprised me ;-)
Thanks again! There is a lot to digest here. All this information has been
really useful.
I will try to put my thoughts together by advancing with the documentation
before
> Yet another bg topic.
:-)
> Mime4J is an effort to remove that dependency in James. There is still a
> lot of work to do to reach that goal (most notably in the mailet-container).
Is that what the DOM is for? I.e., is this supposed to be the MIME message you
are talking about?
—>
Thanks Benoit, very helpful! It does lead to more questions, though. :-)
> - **mailet** are separated in an effort to serve as a specification for...
> - **mailbox** as presented below is a storage service for the server….
> - **protocols** is an effort to provide mail protocol utility for...
>
>> 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
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
> 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!
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
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
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
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
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
> 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.
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
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.
Hello Raphaël,
> Someone (aka Michael Bailly) suggested "Flavor" instead of "Product". I also
> think it's a nice way to speak about a product already configured to match
> some specific needs.
Yes, “flavor” could be a good concept. I think that is for variations of a
“thing” that
Hi Raphaël,
> Yes, that's the global idea. But we differ about what is the "thing". For me
> the "thing", or the product is James, a mail server where you can easily
> configure a specific business logic. So the product serves different
> protocols: SMTP, IMAP, JMAP, etc., can be managed
> To configure a storage component to use one type of another makes perfect
> sense to me. So to configure swift vs. s3 or DB vs. Cassandra, that makes
> good sense to me. But not to be able to configure filesystem vs. RDB does not
> make sense to me.
Maybe I have reconciled this in my mind.
> We could very well change the "e" meaning in the James acronym too.
>
> Something like `JAva Mail Extensible Server/Solutions` ?
Thanks for thinking about this.
The “JAM” part of “JAMES” brought to mind “JAMstack”.
Taken from this page: https://jamstack.wtf/
[JAM = JavaScript + APIs +
Hi Benoit:
> I gave a shot at defining:
>
> - Core components, that offers services at heart of James
> - Utility components, that offers services core-components
> implementations can rely on.
> - Mailbox sub-components.
Wow, there is a lot here! It will take me some time to digest, but
Hi Matthieu,
> We somehow already analyzed that topic in the past and this is what we came
> to :
>
> 1. James is a mail server that can integrate your business logic
> 2. James is a mail framework : you can build you application and specific
> needs into James
> 3. James is a set of
>> Do you think we could keep the acronym `James`?
>
> But we can very well keep James name without it being an acronym.
I agree. In the current version of the new docs, that is indeed the solution I
have taken.
The only question is: do we just use “James” without any explanation and leave
it
>> Does this go in the right direction?
>
> Yes
Thank you once again, Benoit.
I will take the documentation in this direction, then.
Cheers,
=David
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For
Hi!
Based on things that Benoit has been explaining to me (in threads such as [1],
[2]), I have been thinking about the top-level description of James.
[1] https://www.mail-archive.com/server-dev@james.apache.org/msg65858.html
>> 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:
> 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
Hi Eugen,
> Quite a long email :) .
Hehehe, yes. Good thing I stopped when I did. Glad it got some dialogue going.
I very much appreciate your reply.
Just a few comments inline.
> I believe the protocols share the protocols-api beacuse they are
> all/mostly all line based protocols.
>
>
>>> Hope it helps.
>>
>> Yes, quite a lot!!
Still true.
> Yes, the client (either a MUA or a MTA) is the remote process talking
> SMTP to our SMTP server via a TCP connection.
Thanks, that clarifies. I misread your last email. Now everything you wrote
makes sense.
So would it be fair to
> I don't think people are interested by an API allowing them to implement
> SMTP themselves. (That is quite some work!)
LOL indeed, and I completely agree. But I don’t think that’s the point I’m
trying to make.
Some organizations may want to create an implementation.
The James team may wish
Hi Benoit,
> In an evening effort, I started writing a documentation skeleton for the
> Distributed James server with the new Antora Documentation.
Awesome, thanks!
> In order to juge the results I came up with (and do some corrections as
> I am new to this technology) I would like to
Hey Benoit,
> Now, that being said, I believe we should always define a "purpose" for
> an API, and here we mixes things in my opinion.
Yes, very good point. I agree 100%
> Are we defining an API for building any arbitrary SMTP server?
My somewhat vague thought is: I get the impression that
> 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
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:
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,
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
> 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
Thanks Benoit.
Now, since I already have your attention on this topic, please allow me to
really push so I can reach some kind of resolution. The resolution will allow
me to figure out how to move forward with several things. Since I have been a
bit stuck the past few days (and growing
Hi!
Please take a look at this image:
—> https://james.apache.org/images/james-smtp-relay.png
I have several questions.
First, is it correct to say that in this image, the “SMTP Service” is an MTA?
Furthermore, is it correct to say that it’s the “terminal” MTA?
How does the mail get
> Hope it helps.
Yes, quite a lot!!
A few clarifications, please.
> SMTP Service is talking TCP with the client. When it is asked to
> deliver a message, it simply calls `enqueue` on the MailQueue.
Can you be more precise about what you mean by “client”?
> As everything happens in the
> Since I am pretty much stuck with the documentation efforts (as I have
> mentioned I need more input from the community if I am to move forward), what
> I think I’ll try to do next is write an “independent” API for SMTP. […]
I spent a few hours on this today, but already I think I am going
Hi there,
I think that my thoughts about components seem to be quite aligned with those
of Eugen, so I won’t really repeat anything here. I agree with pretty much
everything he writes about the advantages of having clean components. Perhaps
the only thing I would point out is that even with
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
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
Hi Eugen,
> Regarding the new documentation website:
> We have automated website building with Gradle and Antora.
Nice work! Thank you very much.
> Once we have enough content I'll ask for a public review on james user
> mailing list and other channels.
Quite a way to go before it’s ready for
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
Hello!
When writing the docs, I came to understand that what we mean by “Mail Server”
is not very clear to me.
There is “SMTP Server” (which is a “Mail Server”).
There is “POP Server” (which is a “Mail Server”).
There is “IMAP Server” (which is a “Mail Server”).
There may be other “things”
> Why not just refer to Apache James as a ‘mail transfer agent’ and then you
> can refer to the LMTP, SMTP, POP3 and IMAP server applications as servers.
Yes, that makes sense.
What I wonder about though is what to do about “Mailets”. There are things in
James that are not “standard”, but are
Thank you for the comments.
> Email has been here for a long time and the terms are pretty well
> established IMO. We should not try to reinvent them and try to adopt and
> perhaps try to explain them in simpler terms.
>
> From https://en.wikipedia.org/wiki/Email_agent_(infrastructure) and
>
> Don't be afraid, debate is sane
Thanks for the reassurance. It’s sometimes difficult in a “new” community to
know how people will take things.
> Commitment is just text and I don't have much trust in text.
Well, if most people here think this way, then there really is no way forward
with
Hi,
Please be in a good mood when you read this. Words can be taken the wrong way.
I am writing this with a big smile on my face, all in good humour.
>>
>>> [... snipped everything ...]
>
> I agree with everything you wrote.
I think you are taking certain things a little too much out of
Hello!
Was nice talking with you all yesterday. Such a nice group! I look forward to
the next discussion.
Anyway, I wanted to start moving forward with the issue of “Community
Development”. As usual, I will start by asking a few questions, then trying to
commit these to the documentation.
Hello,
As I mentioned during our call, I need your help so I can continue to move
forward with the documentation.
My first questions are about SMTP.
* How does James model SMTP?
* Where can I find SMTP related concepts in the code?
* What are the related modules?
* How would I build my own
> My first questions are about SMTP.
After a bit of resisting, I finally bit the bullet and downloaded IntelliJ. I
am now able to compile and navigate my way through the code in an IDE, so I
should be able to make better progress.
> * How does James model SMTP?
> * Where can I find SMTP
> An extension developer is a special kind of user, who understands and
> leverage James extension mechanism (so yes).
Makes sense! And I like the term “Extension Developer” as opposed to “(James)
Developer”.
I am currently “User”, but I want to soon become an “Extension Developer”. For
me
> We don't have examples for this yet.
>
> The closer could be
> https://github.com/apache/james-project/blob/master/server/container/guice/cassandra-ldap-guice/src/main/java/org/apache/james/CassandraLdapJamesServerMain.java
> bringing in LDAP UsersRepository for cassandra-guice server.
>> * What is meant by “James User” (as opposed to “Developer")?
> In my opinion a user is someone running James. He don't compile nor
> write James related code.
So does this mean that writing code for a Mailet or a Listener or whatever is
done by a “Developer”?
Or would a “Mailet Developer” be
>> Ideally, I would like to use my existing useradmin / auth system, which has
>> a REST interface.
>
> Nowadays, you would write a UsersRepository implementation interacting
> with your REST interface. You would define your custom server reusing
> jpa-guice prepackages server guice module but
>> When attempting to use the CLI, I encounter this warning:
> Very likely we have 2 logging dependencies on the classpath.
>
> This needs to be rationalised. I will add this to JAMES-3214 as this
> relates to cleaning dependency mess…
Perfect, thank you!
signature.asc
Description: Message
> In my opinion…
Thank you for the informative reply!
I will wait to see if anybody else provides an opinion before I respond.
Cheers,
=David
signature.asc
Description: Message signed with OpenPGP
> It would be more helpfull if you can name your integration target. What
> is your Identity Provider?
Hi Eugen,
I have my own custom provider based on Firebase Auth (long story), but OpenID
Connect would be a great (and very general) solution!
Cheers,
=David
signature.asc
Description:
> I think it's a good discussion toe establish the terminology and have
> the same view of this.
>
> I hope it gets into the docs as a term deffinition or something similar.
>
> +1 for Extension Developer.
I am thinking something like:
* James User
- Does not compile any code
- Does
I am moving a comment from Benoit to this new thread:
> Also I would like to differentiate the terms "offering" (what do we
> deliver as part of the James project, who do it targets, and how easy
> should it be to use) from the term "support" which in my view implies
> "how fast you solve my
> I prefer the term "operator" to "user”.
That’s fine. So I will collapse all those previous definitions into the single
“Operator”.
When we say “User”, it will therefore mean:
>> * Email User
>> - Just uses email without any notion of what server is providing the
>> service
I think it’s
> Please consider using the Persona terms for the above, as to not over
> load the "user".
I know the term “Persona” in marketing. It is used for target market
segmentation and product development. From how I have seen it used (at least in
a Lean Startup context), is usually posed as a
>> Don't be afraid, debate is sane
>
> Thanks for the reassurance. It’s sometimes difficult in a “new” community to
> know how people will take things.
Right now, since I am new to the community, I don’t feel that it would be
appropriate for me to debate any issue too strongly, let alone an
Hello!
I have a question about the James architecture, and how it relates to how James
components are composed.
It is my understanding that there are already some basic concepts that are
well-known, like SMTP Server, IMAP Server etc. (Or if you prefer, MTA etc.)
So why is it that these are
> What we say is: "you are all welcome, come join us, we'll try to help
> as much as we can". It's very different from both "we commit to help
> you" and to "you won't get any support".
Ok, then let me focus on precisely this point, in the hope of nailing down some
kind of agreement.
> you are
Hi,
I get the impression that everybody here speaks French.
Would it be ok to do the call in French instead of English?
Cheers,
=David
> On Jun 24, 2020, at 20:41, Tellier Benoit wrote:
>
> Reminder ;-)
>
> Time: Thursday 25th June 2020, from 8am UTC to 9am UTC
>
> Location:
Hi,
Thanks for thinking about this.
>> When writing the docs, I came to understand that what we mean by “Mail
>> Server” is not very clear to me.
> Somehow. Let me give a try at generifying this:
>
> A mail server is a software whose responsibility is storing,
> transferring or processing
> Let's then dig further[…]
Thanks!
I think I have enough to do another iteration, then we can continue the
discussion from the new documentation if needed.
Cheers,
=David
signature.asc
Description: Message signed with OpenPGP
Hi,
I think it is best to let others decide, but I wanted to respond just to this
part:
> As such the JAMES project would ship a set of servers:
> - The "demo" server
> - The "simple" server
> - The "distributed" server
I don’t recall how we got there, but the current docs use:
- Demo
Hi!
I am turning my attention to:
—> https://james.leangen.net/main/3.5/servers/local.html
Which is introduced here:
—> https://james.leangen.net/main/3.5/servers/index.html
However, since unfortunately I am still oblivious to too many James concepts, I
do not yet know how to set
Hi Matthieu,
> I copy/paste the summary here to be sure we are talking about the same
> thing.
Yes, we are indeed talking about the same thing.
> The right `flavor` is the JPA/Guice one. Docker image on github is
> linagora/james-jpa-guice
Ok, thank you! You have given me a lot to work with.
Hi Matthieu,
> I'm very happy having people to give their opinions, it means, to me,
> we have some kind of community.
Yes, I agree. It must remain respectful and cordial, though. I hope I was able
to do that.
>> I totally agree with the point: one should not confuse “complex” with
>>
1 - 100 of 487 matches
Mail list logo
