GNOME Bugzilla – Bug 341579
better SMTP error messages
Last modified: 2008-06-26 12:58:37 UTC
The current SMTP code will use an error string taken from rfc0821 (matched against the actual numeric error code) in the cases where the server does not support the ENHANCEDSTATUSCODES extension... these error messages are often cryptic to users. It might be useful to extract the error strings that may appear after the numeric error code in much the same way as the ENHANCEDSTATUSCODES code does (which may or may not work depending on the user's locale charset matching the server charset needed for conversion to UTF-8 - I wonder if the ENHANCEDSTATUSCODES code handles this properly and if we can just do what it does?).
RFC2821 is clear that commands and responses are ASCII. If you encounter a server which gives a non-ASCII response, it is quite simply broken. Appendix A: The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero. Service extensions may modify this rule to permit transmission of full 8-bit data bytes as part of the message body, but not in SMTP commands or responses. Of course, it's good to make a best-effort in the case of broken servers, but you don't have to beat yourself up about it. I'd suggest that we should do it like this: 1. If it's valid UTF-8 (which includes ASCII), treat it as such. 2. Else, if the user's local charset is not UTF-8, assume the message is in the user's local charset. This is a reasonable guess because people will often be using an SMTP server which is set up for them by someone who speaks the same language (and uses the same charset). 3. Else, assume ISO8859-1 -- in the absence of anything better to do.
yea, that follows what I had ben thinking too.
Created attachment 100754 [details] [review] proposed eds patch for evolution-data-server; Say something like this? I really do not care about other character sets, the most worst thing which can happen is the text in dialog will be broken, but it's fault of SMTP server, because of the RFC: command response uses 7-bit encoding. (or something like that there)
this patch looks ok so long as it works (I can't test it)
That's my problem, too, I cannot test it properly either (I tested only on some fake error, when I did lye that there was an error, but it's not the same). David, are you able to try and test it for us?
Not right now; I'm kind of busy. Maybe in a week or two. Better still, point it at one of my machines like bombadil.infradead.org and do naughty things (like having an underscore in your HELO), and check you get told to sod off correctly :) It won't take much for me to tune the error messages and even (temporarily, since it's an RFC violation) put UTF-8 or legacy charsets in them. I can do that while you test, if you like?
Created attachment 100966 [details] [review] proposed eds patch ][ for evolution-data-server; after a testing with David's help, we got this patch as result of our work.
Although Milan's patch works fine, it highlights a problem which already existed elsewhere. When HELO fails, Evolution silently ignores the error and continues. So imagine the following SMTP conversation: << 220 ESMTP >> HELO [10.0.0.1] << 451-Sorry, this server is currently down for maintenance. << 451-Scheduled maintenance downtime is on the last Friday of each month, << 451 between the hours of 22:00-23:00 UTC. >> MAIL FROM:<dwmw2@infradead.org> << 550 You must identify yourself with HELO or EHLO before sending mail Evolution will currently report that final error message, instead of the more useful first error.
Milan, you want to debug more into the later issue or push this atm and work more? I would leave the call to you.
We had a chat with David that day before he wrote it here, it will be a new bug (hint David), and I will commit this today.
Committed to trunk. Committed revision 8305.
For thing in comment #8 created bug #504837.
*** Bug 332939 has been marked as a duplicate of this bug. ***
*** Bug 364248 has been marked as a duplicate of this bug. ***