Hello David,

I'll give it a try, but my knowledge is not that extensive at the moment.

SMTP is a protocol for for transfering email (as the name suggests :D )
https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol .

A short, probably not entirely correct summary follows, with references
to Apache James codebase follows:

Users connect to the SMTP and pass the email message that they want to send.

The SMTP optionally validates user credentials (highly recommended,
otherwise you are an Open Relay = spam gateway).

The SMTP server will process the email to identify if it is local or
remote email.

A local email is email for a domain "known/managed" by the same admin as
the SMTP server.

This local email will be delivered to the users inbox directly by
storing it in the mail storage.

A remote email address - the domain part is not managed by the SMTP system.

In this case the SMTP server will have to forward the email to another
SMTP server.

For remote delivery, this SMTP server will look for the MX record for
the domain found in the email destination address.

It will connect to that server and via SMTP protocol and send it the email.

When doing remote delivery, the SMTP server usually performs DNS
checking, DKIM validation, etc.

The SMTP server uses spooling system - a processing queue (like the
printer) for delivering emails since:

- Email deliver fails and needs to be retried

- Remote email delivery takes time and we need to store the email safely
from the time we accept it from the mail user agent (MUA) until we
deliver it to the mailbox or to another remote system.


References to James artifacts:

* Parsing of the SMTP protocol is done in protocols/smtp module .

We leverage netty network library for protocol parsing.

When we parse the protocol we transform string lines to SMTP
commands/actions that we need to implement via code.

This is the low level API independent of other Apache James modules.

Inside James we implement and provide actions for each SMTP protocol
command in the server/protocols/protocols-smtp module.

This module hooks into James specific libraries and provides more meat
to the API.

**server/protocols/protocols-smtp** is normally what you need to get going.

In the current James setup, we take the classes from
server/protocols/protocols-smtp and use Guice ( a dependency injection /
wiring framework) to instantiate the SMTP components and wire them
together in a form that will work for us.

The guice wiring is available in server/container/guice/protocols/smtp .

The guice module is a thin wrapper that provides just the wiring and
builds a reusable guice module.

The above pattern is repeated all over James, so as you can see we do
have some separation of API and implementation, but not as pure as you
find in other places.


Also SMTP needs a queue to spool email and we have several
implementation of that: RabbitMQ, Apache ActiveMQ, File queue, etc

See modules in server/queue .

Also SMTP uses dns and we use the dns modules in James, see
server/dns-service for that.

Also SMTP needs to perform user authentication and that part is managed
by server/data modules (See User API packages and classes in data-api ).

All of the above modules follow the same guice pattern presented above.


La 26.06.2020 08:45, David Leangen a scris:
> 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 SMTP server?
> * What other information is relevant to SMTP that I may want to include?
>
>
> Thanks!
> =David
>
>
-- 
Eugen Stan
+40720 898 747 / netdava.com

<<attachment: eugen_stan.vcf>>

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to