"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > I also noticed that TMDA/Auth.py contains a nearly identical function > (L254). Do these fixes need to be applied there as well?
I'm tracking this down because of a question on -users. Originally, another poster had troubles with tmda-ofmipd and I meant to update this and forgot. The problem that today's poster mentioned reminded me. When I went back to answer his question, I discovered that he was talking about tmda-cgi. That's when I discovered Auth.py. It's not used by anything but tmda-cgi, but apparently the idea was that we would eventually move tmda-ofmipd to use it, too. The problem is, I'm scared of it. It is, to put it kindly, a work in progress. To answer your specific question, the test for whether it needs to define its own IMAP4_SSL class or not looks correct in Auth.py. It imports imaplib.py and attempts to access the IMAP4_SSL class. Only if it is unsuccessful does it create its own. That seems right to me. Something is obviously still screwy, though, since 'remote' is being passed to the IMAP4_SSL class's __init__. When I had looked at tmda-ofmipd, I believed that was because of the incorrect use of 'self.host' and 'self.port' in tmda-ofmipd's IMAP4_SSL.open(). That bug would only manifest itself when tmda-ofmipd's class descended from the IMAP class in Python 2.3 and *not* in previous Python versions and the only reason it would do that was because of the bogus version test. Now... I'm not so sure. Because of the way Auth.py decides whether to create its own IMAP4_SSL class, the problem should never occur, but it still seems to be happening, so I need to look at this a little more. There's nothing wrong with the tmda-ofmipd fixes I checked in, but there may be more to the problem. I'll keep looking. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
