I wasn't checking the status of quit. As it turns out,
the transport implementation did not check the status of any of
command. It merely stuffed the whole message into the smtp
server and closed the connection. It never waited for a response
from the server. If the transport code hadn't been open source,
I would of never found the problem. Bad code is bad code - can't
help that.
In any case, why does smtpd return 256 and throw away the
mail? I have records of a good transaction (all commands get a +OK)
yet smtpd exits with 256 and the mail is eternally lost.
-Tom
> > I had a CR/LF problem with a JavaMail implementation. I used
> > recordio to track down the problem. I first noticed the problem in
> > the logs, whem smtpd would exit with a status of 256. The remote
> > unit would think the mail was delivered because smtpd said OK when
> > quit was given, but the exit code indicates that something failed.
> > It wasn't until I recorded the whole session and saw the note about
> > cr/lf that I figured out what the problem was. Shouldn't smtpd
> > give an error back to the remote unit if it does not intend to
> > deliver the mail? All the 'bad' mails ended up in /dev/null -
> > fully delivered from the remote side, completely lost by qmail.
>
> You shouldn't be checking the status of the quit command. That is going
> to succeed. You should be checking the status of the data command.
--
+-------------------------------------------------------------------+
+ Thomas M. Sasala, Electrical Engineer [EMAIL PROTECTED] +
+ MRJ Technology Solutions http://www.mrj.com +
+ 10461 White Granite Drive, Suite 102 (W)(703)277-1714 +
+ Oakton, VA 22124 (F)(703)277-1702 +
+-------------------------------------------------------------------+
