-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason R. Mastaler wrote: > Stephen Warren <[EMAIL PROTECTED]> writes: > >> On this specific point - what should the behavior be? I'm honestly >> confused *why* the person who reported the problem with the >> exception handler that I added thought the behavior was incorrect - >> there *was* a problem, and it was reported as an SMTP error message. > > Take another look at the thread[1]. The user sent mail to a malformed > address, and tmda-ofmipd returned an error. That's not the behavior > one expects when they send mail to a bogus address. They send the > message, it gets transferred, and the relaying SMTP server bounces it > back with an informative message. If tmda-ofmipd is circumventing > this process, it's going to cause confusion, not necessarily because > tmda-ofmipd is wrong for trapping an exception, but that it's not the > expected behavior.
Now I recall. So, my points: 1) I believe that the underlying SMTP server itself refused to accept the message (i.e. returned an SMTP error code for the MAIL FROM, RCPT or DATA command). It was not actually tmda-ofmipd that rejected the message as unparseable, but the SMTP server itself. I think I thought otherwise before, simply because the exception traces weren't that clear to me and I didn't spend enough time analyzing them. 2) The above SMTP server behavior is pretty typical in the case where one sends to an unknown local user (and as evidenced by the original problem report, when the SMTP server can't even parse the address). For example, if I connect to my postfix system (directly, or proxied via tmda-ofmipd - doesn't matter), and send mail to [EMAIL PROTECTED], postfix won't even accept the mail to generate a bounce, but instead will return an SMTP error code. In this case, tmda-ofmipd must pass that error back to the client somehow. postfix will accept mail (and generate bounces) for non-local recipients e.g when I send to [EMAIL PROTECTED], or delivery timeouts etc. etc. 3) Think of what happens when the underlying SMTP server runs out of disk space, processes or whatever, and physically can't accept the mail to generate a bounce later - again, we must pass such errors directly back to the mail client. 4) tmda-ofmipd also can internally generate some errors. For example, a syntax error in the outbound filter. This is in fact the situation that caused me to originally add the exception handler. > No, I think the relaying SMTP server (Postfix, qmail, etc) should deal > with this and report this as problem to the user. When a user sends > mail to a bogus address, he expects to find a bounced message in his > mailbox informing him of this. This is just one example, but I think > the general principle is important. For the reasons above, I don't think this is possible in general. > I also want to get away from trying to code around deficiencies in > Thunderbird. Thunderbird handles some of these cases differently > (incorrectly I believe) than every other MUA. tmda-ofmipd shouldn't > be covering Thunderbird's ass. By doing so it prevents those bugs > from being fixed in Thunderbird. True, Thunderbird's behavior is a bug in Thunderbird. One day, it will be fixed (maybe it already is - I haven't been able to reproduce the connection drop recently to test this!) > So I'm just saying, let's make sure > we are thinking about these issues from a wide and general > perspective. True. I certainly added the SMTP error code reporting (instead of previous dropped connections) to solve the Thunderbird issue. However, I also believe that simply dropping the connection is completely the wrong thing to do in *any* situation, simply because that's not how the SMTP protocol works - errors are indicated by passing back well-formed error codes, not by dropping the connection. So, I believe I'd still solve the issue the way I did even if I wasn't a Thunderbird user, honestly (not that I probably would have ever found the issue, but...) Solving this would also solve the test-with-telnet issue - a valid error message would be sent back to the end user immediately; much easier to see the error than checking a log-file or separate window for the debug log. So, I believe returning SMTP error codes instead of dropping the connection makes tmda-ofmipd more RFC compliant, and more debuggable (and debugging mail systems can be hard enough - the more help the better!) Oh, and finally - even with a 100% correct mail client, sending back error messages (with useful text) allows the MUA to give that error message to the user (who can then pass it to tech support). Simply dropping the connection only allows the MUA to say "connection dropped", not why. One note: I believe tmda-ofmipd currently does usually send back SMTP error codes with the exception text, just like I'd like it to. However, there are obviously a couple of cases where that doesn't currently happen for some reason. That's what I'd like to fix - to make things consistent. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFVWDthk3bo0lNTrURAk+0AKDILDQZCvxOi84AahDXe1v1ADjEaACgnf/A viWmwHlcZbZWKTfs+jjsV5o= =GLbe -----END PGP SIGNATURE----- _____________________________________________ tmda-users mailing list (tmda-users@tmda.net) http://tmda.net/lists/listinfo/tmda-users
