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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.