You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by David Leangen <ap...@leangen.net> on 2020/07/08 07:21:15 UTC
SMTP Relay (Was: Queuing vs. spooling)
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?
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Eugen Stan <eu...@netdava.com>.
Great.
And as you said, it is important that whoever can answer some questions,
please find the time to do it.
You are helping yourself - the community grows, James grows, we all get
to benefit.
La 09.07.2020 05:05, Tellier Benoit a scris:
> Le 09/07/2020 à 07:42, David Leangen a écrit :
>> 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.
> It definitely worth it.
>
> +1 on the conclusion of this thread.
>
> Benoit
>> Thanks for all the help so far. Please keep it coming!!
>>
>>
>> Cheers,
>> =David
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Tellier Benoit <bt...@apache.org>.
Le 09/07/2020 à 07:42, David Leangen a écrit :
> 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.
It definitely worth it.
+1 on the conclusion of this thread.
Benoit
>
> Thanks for all the help so far. Please keep it coming!!
>
>
> Cheers,
> =David
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by David Leangen <ap...@leangen.net>.
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
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Eugen Stan <eu...@netdava.com>.
Hi.
I don't have something to add to this thread specifically, but I would
like to point out that:
GIven the discussion around the specific topics I think we are getting
our documentation.
All we need to do now is copy paste it, curate it and edited in asciidoc
format.
I'll even put in the links to he mailing list archive / thread as
reference.
@David: If you can do just that: ask questions and compile the answers
it would be a huge win for us.
You don't even have to be very creative about it: it's good material.
Once I'm done with the automation I would like for us to 'get together'
in a (virtual) party and migrate the old website and get the new one out
the door.
Also, I'll try to find some time in the next days to work together on
some specific tasks
I believe it will be better than alone :).
Regards,
La 08.07.2020 11:49, Tellier Benoit a scris:
> Le 08/07/2020 à 15:33, David Leangen a écrit :
>> 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.
> Correct
>> 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.
> Ouch. Complex and old code relying on javax.mail is waiting you ^^
>> 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.
> It do start DeliveryRunnable that consume the outgoing queue. Relaying
> happens there.
>> So the queue-api seems now quite important.
> I confirm it is.
>> 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.
> It is guice agnostic. Look inside RemoteDelivery::init...
>> I will investigate further, but in the meantime, can somebody please point me in the right direction to help speed up my journey?
>>
> Did I just do that or you need more information?
>
> Cheers,
>
> Benoit
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Tellier Benoit <bt...@apache.org>.
Le 08/07/2020 à 15:33, David Leangen a écrit :
> 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.
Correct
> 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.
Ouch. Complex and old code relying on javax.mail is waiting you ^^
> 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.
It do start DeliveryRunnable that consume the outgoing queue. Relaying
happens there.
> So the queue-api seems now quite important.
I confirm it is.
> 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.
It is guice agnostic. Look inside RemoteDelivery::init...
> I will investigate further, but in the meantime, can somebody please point me in the right direction to help speed up my journey?
>
Did I just do that or you need more information?
Cheers,
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by David Leangen <ap...@leangen.net>.
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
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Tellier Benoit <bt...@apache.org>.
Le 08/07/2020 à 14:39, David Leangen a écrit :
>> 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?
No they don't.
They encapsulate what a "Mail" (a Mime message with its transport
context) is and transform it.
They can for instance be used after a JMAP submission servers (as users
can send mails via JMAP too)
Mailet are just a very simple Java interface. There is no hard
dependency to 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by David Leangen <ap...@leangen.net>.
> 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
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Matthieu Baechler <ma...@apache.org>.
On Wed, 2020-07-08 at 16:21 +0900, David Leangen wrote:
> 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?
>
> 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?
>
The only wrong thing about this picture is the SMTP Service before
"Outgoing".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.
> -- Matthieu Baechler
Re: SMTP Relay (Was: Queuing vs. spooling)
Posted by Tellier Benoit <bt...@apache.org>.
Nice image!
- there is a queue before SMTP outgoing service (as you don't want to
handle SMTP synchronously anyway)
client -> SMTP (in, as a server) -> queue (spool) -> Processing chain ->
Queue (outgoing) -> RemoteDelivery runnable
Also as Matthieu said, RemoteDelivery is a side effect of the current
Processing chain.
Cheers,
Benoit
Le 08/07/2020 à 14:21, David Leangen a écrit :
>
> 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?
>