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
