Re: SMTP Relay (Was: Queuing vs. spooling)
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-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: SMTP Relay (Was: Queuing vs. spooling)
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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: SMTP Relay (Was: Queuing vs. spooling)
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)
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-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: SMTP Relay (Was: Queuing vs. spooling)
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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: SMTP Relay (Was: Queuing vs. spooling)
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)
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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: SMTP Relay (Was: Queuing vs. spooling)
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? >
Re: SMTP Relay (Was: Queuing vs. spooling)
> 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: SMTP Relay (Was: Queuing vs. spooling)
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
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? signature.asc Description: Message signed with OpenPGP
