Re: Possible minor bug in tmda-ofmipd
Stephen Warren <[email protected]>
| Newsgroups | gmane.mail.spam.tmda.user |
|---|---|
| Message-ID | <[email protected]> |
Jason R. Mastaler wrote: > Stephen Warren <[email protected]> writes: > >> Oh, the exception handling code is totally required for Thunderbird >> at least - if Thunderbird sees a dropped connection instead of an >> SMTP response message, it'll think the message was successfully >> handed off to the SMTP server, when in fact it wasn't, so the >> message never gets sent, and the user never receives any >> notification! > > The above look allot like a bug report. ;) > > Tbird is in the minority then, and perhaps it's the only one who has > this problem. Would it make sense to turn on this new exception > handling code with an optional command-line switch, but not by > default? Food for thought. So, I just tested: a) Sending an email with an envelope recipient in an invalid format b) Sending an email to a non-existent local user on the server ... using tmda-inject, the underlying implementation behind tmda-ofmipd, and tmda-ofmipd itself. In all cases, the error itself is raised by the mail server, not any part of TMDA, so TMDA isn't performing any "extra" validation. My thoughts on tmda-ofmipd's current behavior etc.: 1) Yes, thunderbird has a nasty bug where it doesn't correctly handle connection drops. At least it did at one time! Even so, tmda-ofmipd's behavior was to simply drop the connection when the exception was raised, and I'd rather see it return an error message than do something nasty like that! 2) It seems that if I remove the new exception handling code, with Python 2.3 at least, the connection doesn't get dropped any more, but is actually caught inside asyncore.py. I originally developed the patch using Python 2.2 or earlier, so I guess the Python behavior has changed. 3) From a user-experience point of view, I'd say the asyncore-generated response message is far worse than the current "Internal exception" message, since the full exception details and traceback are sent back to the client. Still, overall, it doesn't seem like the extra exception handling code is actually required any more, so I can remove it. However, the user visible behavior won't change at all, just the content of the error message.
signature.asc
(application/pgp-signature, 250 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFJdm4hk3bo0lNTrURAqfSAJ0etxtcgLEnJu/J1VXy1K2w9vMZYQCghBvp 2Wcu1ljhsPEJ0hsM5cCs56A= =Y6Fq -----END PGP SIGNATURE-----