>From the rfc, it looks like the HELO/EHLO is expected, although it doesn't say MUST. Their examples all show a subsequent EHLO.
Do you know of any tools that provide an interactive telnet-style interface that *accepts* connections on a port? I'd like to interrogate my Exchange server's ATRN attempts that way. Maybe it wouldn't be that bad to implement. Hmmm. Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 7:47 PM > To: James Users List > Subject: Re: ATRN > > 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:james-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:james-user- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
