You know, I've been thinking about it, and I don't think it would be that bad to build your own delivery implementation. After the ATRN command is executed, all you really need to do is something like this...
MAIL FROM: <sender> (parse configuration message) RCPT TO: <recipient1> (parse confirmation message) RCPT TO: <recipient2> (parse confirmation message) DATA (parse confirmation message) (have the mime message write to the socket, using dot stuffing, and James already has an outputstream to help you there) ... (repeat ad naseum) QUIT (parse confirmation message and quit) I guess my point of all this is that the servers will already have talked (I don't think you need to HELO/EHLO again, which is one hard part), and I think you might get away with a basic implementation as opposed to one that can handle numerous error conditions, poor implementations, and other issues that you'd need for a normal transport. Initially you just need it to run correctly with your server, and then as others need ATRN support to grab from their server software, then we can find the problems and patch. It's actually a nice way to build our own SMTP transport... I'm somewhat encouraged. Maybe they won't mind if you half look over their code while you write an independent implementation. Again, I'm hoping it won't be that bad. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ Jeff Schnitzer wrote: > I went through the code and you're right, it doesn't look like it would > be all that hard to implement - except for the JavaMail problem. I'll > send a request to [EMAIL PROTECTED] asking that they accommodate our > need, but who knows if that will help. I'll cc james-dev. > > I just spent some time going through the JavaMail source to see if there > is any possible way of hooking into it. It's bleak. Anything that > could possibly be of use is private. Even package visibility would give > me an entry point. And of course we can't redistribute a modified > JavaMail... I *detest* Sun's idea of open source. Grrrrr. > > Yep, from the state chart in the rfc > (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2645.html), ATRN only goes > one-way. There is no flipping back. Seems like it would be *really* > easy to add ATRN to James if only there was a > javax.mail.Service.connect(Socket s). > > :-( > > Thanks, > Jeff Schnitzer > [EMAIL PROTECTED] > > > ----- Original Message ----- > From: Serge Knystautas > Subject: Re: ATRN > Date: Wed, 12 Jun 2002 04:45:18 -0700 > > > Jeff, > > James doesn't support it right now. Part of the problem is that we're > using JavaMail's transport API to deliver messages, so we'd have to > write out own SMTP delivery code to support ATRN. I conceptually > understand how ATRN works as well, but don't know how you would go about > writing that in the connection handling code that wouldn't look really > ugly. > > James can queue mail however necessary, and the SMTP handling code is > nice in it's own class. As to whether this would take a week if more up > to your ability and how much time in that week you really have. Would > you see that ATRN supports only 1 flip (i.e., we start as the server > role and can flip to be the clip role, but won't flip back)? If that's > the case, it might not be so hard. > > It would be kind of a nice feature. I would suggest you start looking > at the code, and maybe it will start making sense quickly. Aside from > the "client" code dependency on JavaMail (which you might be able to > work through as a hack), James is pretty much in a good position to > support ATRN. > -- > 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]>
