I
am
working with
Apache James.
Basically, first, a few words I'm working at
Lina Gora. Our mission is to promote data sovereignty and
especially give the tools for organization to communicate
together without using big gaps.
So we are working on a suit called twig workplace with
twig mail for e-mail, twig that is relying on matrix for the
chat and also file sharing.
So as part of this development effort, we were looking back in
the days for an e-mail server that is easy to scale, at the
time we were looking for a file sharing.
So we are looking for a file sharing.
So we are looking for a file sharing.
So we are looking for an e-mail server that is easy to
scale.
At the time we did not hear yet the talk about aerogram.
We were looking for a modern e-mail protocol.
Hopefully we already heard about Ricardo's stuff called
J-Map protocol.
And we also needed to be able to do deep integrations inside
the mail server.
So we started with the protocol.
I am sorry, I am a bit frustrated.
I did not get to speak about J-Map so we will take one minute
to do so.
We started implementing J-Map into Apache James back in
2015.
Before even the normalization effort started within the IETF.
We are big fans of I-Map.
We implemented twig mail client in Flutter.
So Odriga is using it.
The Dart dependency to write J-Map CLI for instance.
Basically we are able to take a mobile team that is not an
expert at all about e-mail and get them to implement a mail client.
The things work fine, works fast.
Synchronization is easy.
Most of the pains of I-Map are lifted.
So twig mail works on multiple platforms, iOS, Android, Web.
And it is also used on top of other mail servers like
StoreWart Labs.
So about the mail server itself, because it is a track about mail
servers, Apache James is part of the Apache foundation.
So it is a track about mail servers.
To my knowledge, it is the only e-mail server that is part of
the foundation and has an open governance model.
It started back in 2003 from Project Jakarta.
So it is kind of a cousin of Tomcat and projects like that.
It is surprisingly influential in the Java world.
The mail that I will present later is kind of the servlet of mail.
So a generic way to write e-mails.
Some of the important people within the Apache Software Foundation
did actually contribute at some point to Apache James.
And Neti Network Library, which is very influential in Java.
Norman Mauer is a previous contributor of Apache James.
So regarding the overall setup, what I recommend actually to use
is the distributed setup for Apache James,
where basically we host metadata in Cassandra.
Big binaries into S3, distributed search with open search.
There was a little licensing problem with Elasticsearch.
And last but not least, RabbitMQ for messaging, things like IMAAP,
IDOL and stuff like that.
Of course, we orchestrate everything and run it on top of Kubernetes
and are integrated with metric systems like Grafana.
So now let's look inside the code.
This is more or less the classical e-mail server architecture.
You've got protocols on the left, SMTP,
IMAAP, which would call the mailbox where the mails are being stored.
And you will submit emails to a mail queue and apply mail processing.
So what's important here to notice is that you've got green dots.
It's not updated the slides, but now you've got a green dot here
that allows you to depend on simple interfaces in Java.
Write Java code in a completely separated project, compile it,
and embed it into Apache James.
Configure it. You have a set of extensions that already exist.
You can use James APIs. You can inject your own component.
And then basically have your code run inside the mail server
without touching the mail server.
And then you can run it on the mail server.
And then you can run it on the mail server.
And then you can run it by switching a single line within that e-mail server.
So sorry that might be complicated to see from the back of the room.
I did not thought about that when I copy and pasted those rectangles.
But basically the mailet container, you take things from within the mail queue.
And the overall design is to have mailets, which is an action,
applied conditionally by a matcher.
So you have two little interfaces that you work with.
The matcher represents a condition.
And you would organize a pair of mailets, a matcher,
inside a processor, which is a stream of execution.
You have a specific mailet that allows to switch a processor.
And a couple of various basic implementations.
All of that is defined in XML and is fully customizable.
I will give you a little example.
So a hello world mailet that is kind enough to look up for the language
and print hello world based on that.
So a mailet would get the mail and applies an action to it.
You can modify the mail.
You can trigger some external APIs and so on and so on.
All I need is to depend on the mailets API.
From there, I compile my project, I get a job,
and I just register it somewhere into my XML configuration,
put the job into external jobs and go.
So back into there, I can just go back to the mailets.
I can just go back to the mailets.
So it's actually quite powerful and you can connect
the different sets of extensions together.
We've been speaking a bit with Daniel about push.
We received a contribution lately to have an IMAP extension
to for push for iOS application.
And basically you are able to plug a mailbox listener
that listens to the mailbox events, register an IMAP app,
and you can get an extension that creates the registrations
and you would be able to get the push working like that.
So that's quite powerful, but James is written in Java.
You have interfaces for everywhere.
Everything has an interface and we rely on inversion
of control with a library called JUSON,
which means that basically you can assemble
your JUSON modules the way you want.
And of course you can reuse existing modules,
which means that you can make your own
tailor-made server with Apache James.
As an example, so because we need to follow the Apache way,
we need to be in open governance.
At Lina Gora, we decided to clearly split the project,
which is Apache James.
That's where open standards go.
That's where the distributed mailbox is.
That's where everything related to modularity,
extensibility is.
And we reuse that as a framework to bundle
our own twig mail servers that have a couple more extensions,
things like autocomplete for email addresses
and stuff like that that are not part of the JMAP standard.
So that we reuse to actually build the JMAP standard
and build our product.
This is a very nice contribution that we did get
back in 2020.
So this is to give you an idea of how you could use James.
The idea is to validate GPG key.
So basically, using the Web Key protocol,
I would submit my key to that modified Apache James
that will send me an email encrypted with the private key
that I've just been uploading.
I would reply to that email,
which would validate the key and serve it there.
So it's proof of concept.
It had not been merged part of James,
but it's to show you that you can really play
and do interesting things with deep integrations.
Who is doing pop free?
It's the guy in the room doing pop free.
Pop free is an awesome protocol
because you don't have a UID
and it's really, really, really simple.
So in France, when you go and see a practitioner,
you would get a repayment order
that would be sent to the National Healthcare Insurance
that of course transits by email.
And every insurance would get a mailbox
receiving millions of dollars.
So you would have emails a day.
And of course, you need to have a damn thing,
geo-replicated on three different locations
and so on and so on.
So I map the latency, it would go crazy.
At least we don't use aerogram.
Volumetry is big.
And of course, they have a very crappy description
of homegrown custom formats
that you need to, that slide, don't do justice.
It's actually a couple thousands of lines of code
to get all of that fitting in Apache James.
The point here, when I arrived on the project,
they were actually able to write tons of mail-in
matchers, listeners and so on and so on themselves
and plug it in together.
So we were also able to rewrite
the storage engine.
And we also had a lot of different
design to be able to leave some
where Cassandra restrictions on
dumpstones and listing millions of
emails.
Another project that we did was actually
to also integrate within MSS Santé.
So that's the mailing system
for French health practitioners.
It has some specific security restrictions
that are related to it.
So we were able to have also some specific
integrations for that customer, like
upload directly, attachments received
into their drive.
So basically, we quite a bunch of extensions
and modularity going on in there.
And surprisingly, even things like
banking applications, that's also email.
And it's very specific.
They have millions of users with very,
very, very tiny mailboxes and it needs
to be cheap.
And they have custom SOAP APIs to
access the messages.
That's also the kind of other things
that you can do with Apache James.
So I did not cover much of the technical
details.
I did do a hands-on session back in
the day in 2019 in the Apache conference
in Berlin.
So if you are interested in getting
more information on the code and
watching some hopefully live coding
that did not go too wrong,
you can do it.
The talk is online.
Thank you very much.
Do you have some questions?
Thank you very much.
Okay.
Let's see your first hand.
Thank you.
So are there any pre-existing
modules for spam filtering
directly with Apache James?
So you need to speak louder because
I did not understood the middle of
the question.
Are there any existing modules for
spam filtering so that you can
use the same language as you
did with Apache James?
So basically we are integrated
with spam assassin and air spam
D, especially with spam assassin
because we are an air spam D
because we have mailbox listeners.
We are able to
live train based on the way you
move messages, your spam filters.
So I think that's a good point.
So I think that's a good point.
So I think that's a good point.
So I think that's a good point.
So I think that's a good point.
So I think that's a good point.
So I think that's a good point.
So my answer is yes, there's
already some integrations.
All right.
Further questions?
So here's somebody.
Yeah, I have a question.
You were talking about these
examples from the health system
and from the banking.
And I'm not sure if I understand
it correctly.
It looked to me like this is very
email as sort of an API in a certain way, right?
For very specific procedures and processes.
And if that's somehow right, you might fix me anyway.
Do you also do special processing of these emails?
I mean, is there any special mind parsing involved
or maybe you can say a few words?
So first your understanding is correct.
Apache James is very modular
and of course it works as a regular email server,
but you can use it for all various corner cases
that could be hard to handle with other technologies.
Regarding mind parsing, I'm also the maintainer
of the Apache MIME 4G parsing library
that of course you can do some pretty complicated
mind parsing within Apache James.
Does it play a role in these use cases,
in this medical or banking one?
Yes.
All right, let's see two more hands.
Maybe first the other guy and you.
Yes, related to the previous question.
Are the emails handled by the healthcare encrypted or?
So they are encrypted and it is transparent
mostly transparent to the work that we are doing
with Apache James for them.
Okay, so is this like transport encrypted
or pay-due encrypted?
Depends, but there's a lot of things going on with S-MIME.
Oh, okay, thanks.
Have you seen any maillets be created
in programming languages like Scala, Groovy, Closure,
those ones based on Java?
So yes, yes, we have a couple of example of Scala mailets.
We use Scala at some parts within Apache James.
For example, the J-Map stack is completely
written in Scala, so yes.
All right, we would still have time
for a quick question if there is any.
One here.
Oh, sorry I didn't.
Ah, sorry.
Yes, okay.
Misunderstanding of mine.
You mentioned POP3, it's very nice,
but I suppose you have IMAP as well.
Is it ready for standard IMAP usage or do I have to?
Sorry, it's a misunderstanding.
POP3 is a horrible protocol,
but it's that one given use case of needing
highly available protocol that can be multi-data centered.
It's so simple that it fits the bills.
Okay, and IMAP is a separate?
We support IMAP, the big range of IMAP extensions.
IMAP is fully supported and we also implement
J-Map as a protocol, so very wide range
of protocols implemented.
Okay, fine.
Thank you, and thank you again, also Benoit.
I hope I didn't see anything.
Thank you.
Thank you.
Thank you.
Thank you.
And yeah, we have one more talk into service session,
which will be Mikkel about MOX.