Hi, Serge > smtp). You add 2 properties to the >javax.mail.Session properties, and
No, this is not correct. This article is good example of how to *hack* java mail to make it SSL enabled but nothing more. I implemented one client (my first version of TLSRemoteDelivery) using this article, but alas this approach is not compatible with Avalon ideology at all. > from fine tuning from years of experience dealing with what other mail I have to think about that, because, honestly, this is my deep concern as well. So far I am not ready to give answer for this your argument. But I still stay for my points from my previous email. > But ultimately, it's all about the code. I'm happy to look over > whatever you would like to submit Did you have time to review my recent submission (SMTPServer-Handler)? Andrei PS could you please share more information about the problems you've experienced with excalibur threads. How I can repeat those? This is *very* critical for James based the solution I am working on. ----- Original Message ----- From: "Serge Knystautas" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, June 05, 2002 4:08 PM Subject: Re: Threads in James: Re: Tomcat + James in a single jvm process > Andrei Ivanov wrote: > > Hi, > > I was about to offer this, just wanted so that initiative is not going from > > me :-) > > > >>We'd be pleased to accept your kind offer to contribute... ;-D > >> > > > > So I have RemoteDelivery mailet which doesn't use JavaMail for transport, > > which uses excalibur threads and cornerstone socket factory (and of course > > support TLS and so on). It works very well ;-D > > Unfortunately I implemented it before I got a chance to look at JavaMail > > sources which were released recently. Now I see some ways to improve it. > > > > Anyway before any further contributions from me I would like to hear from > > Serge about my improvements to SMTPServer-Handler submitted recently :-) > > > > Andrei > > Well, I'm not really enamored with refactoring working James code just > because Avalon provides functionality XYZ. I can understand the > consistency argument. However, I also have found the Avalon thread > pooler to be less reliable than the quick and dirty approach used by > RemoteDelivery (periodically I've had to restart James because the spool > manager threads had all died/hung while I haven't seen this with remote > delivery). > > I would like to remove the JavaMail delivery dependency because JavaMail > is not really a server-geared API. That said, SMTP is an incredibly > challenging API not because of its complexity, but because it's been > around for so long and there are so many liberties other servers take > with it. The settings that RemoteDelivery passes to the Transport are > from fine tuning from years of experience dealing with what other mail > servers can stand to hear. Introducing a whole new codebase can be > extremely risky, because even if you can't deliver to 5% of the mail > servers out there, you're going to hear about it (but probably not until > a couple of weeks of bounces have been going on). > > As for SSL transport delivery, I think that's a reason to stick with > JavaMail actually... it's much more standard and well documented than > moving to a custom SMTP implementation and Avalon sockets. Here's a > good article on the matter > http://www.javaworld.com/javaworld/javatips/jw-javatip115.html?remote_addr=2 09.1.23.157&user_agent=Ultraseek/IDG.net > (this talks about securing other providers, but the same should work for > smtp). You add 2 properties to the javax.mail.Session properties, and > boom, you've got SMTP w/SSL. Doesn't seem like we need to refactor there. > > But ultimately, it's all about the code. I'm happy to look over > whatever you would like to submit, and I'll let you know what I think. > I just wanted to share some of my reservations going into this. > -- > Serge Knystautas > Loki Technologies - Unstoppable Websites > http://www.lokitech.com > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
