On Tue, 23 Jan 2007 23:48:59 GMT, py <[EMAIL PROTECTED]> wrote: >Hi, Jean Paul. > >I read your code with interest. I wonder, does twisted also raise the socket >error or does it know >about this apparently well-known and often ignored incompatibility between the >standard and >the implementations?
Twisted delivers disconnection notification by passing an exception to a method on a protocol instance. So, whether it dealt with this SSL behavior or not, you wouldn't see an exception being raised from the program I posted. However, if one implements connectionLost (the method which Twisted calls on disconnect), if SSL shutdown isn't done cleanly, you will see an SSL exception object instead of an exception which indicates clean shutdown. However, since the example I posted didn't actually directly interact with any protocol object at all, all of this is hidden. The program will appear to succeed completely with no error, because the success condition it defines is for the message to have been accepted by the remote host, not for the socket to have been closed cleanly. > >Something else has occurred to me. After starting tls, all the xmitted >commands and data are encrypted before they leave the client machine. >so obviously they have to be decrypted by the server's socket lib before the >smtp daemon can do what it's supposed to do. >but i wonder if the encryption of the trailing \n.\n has something to do with >the socket error, given that >the error msg says something about premature EOF. As to this, I'm not sure. A cursory glance at smtplib.py suggests it is at least trying to handling the \r\n.\r\n sequence which terminates a DATA command correctly. I'm not sure why you needed to add your own . when you used it. I think the SSL error is most likely unrelated, though. I have seen it from gmail's servers before as well. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list