Bug 201 - Misleading error messages after SMTP errors.
: Misleading error messages after SMTP errors.
Status: RESOLVED WONTFIX
Product: X-Discontinued
osso-email
: 1.1
: All Maemo
: Medium normal (vote)
: ---
Assigned To: Dirk-Jan C. Binnema
: email-deprecated-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2005-11-02 15:49 UTC by David Woodhouse
Modified: 2008-12-06 15:50 UTC (History)
1 user (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description David Woodhouse (reporter) 2005-11-02 15:49:34 UTC
When an incorrect HELO greeting (see bug #200) is rejected by the server, the
mail client tells me "Recipient not found on server". I'm not entirely sure
where that error message came from -- the server said something _entirely_
different to that. But it's very wrong :)

We should report the text which the server returns in its rejection. That's what
it's there for.
Comment 1 Dirk-Jan C. Binnema nokia 2005-11-14 15:10:33 UTC
(In reply to comment #0)
> When an incorrect HELO greeting (see bug #200) is rejected by the server, the
> mail client tells me "Recipient not found on server". I'm not entirely sure
> where that error message came from -- the server said something _entirely_
> different to that. But it's very wrong :)

Sure. That is misleading. We will fix this in some future release (sorry, cannot
be anymore specific) 
 
> We should report the text which the server returns in its rejection. That's what
> it's there for.

Well, I'm not sure our i10n people would be happy with that...
Comment 2 David Woodhouse (reporter) 2005-11-14 15:39:01 UTC
I see no reason why i18n should be a problem.

Aside from the fact that the local mail server is probably going to be talking
back to the user in their own language anyway, it's _always_ better to display
that error message rather than just making something up, because at least that
message is expected to be _accurate_.

You can add your own localised 'Delivery failed' text too, of course, but
there's no justification for refusing to display the helpful error message which
the SMTP server gave you. 

To refuse to display the SMTP message "because it might not be in the local
language" makes about as much sense as refusing to display mails for the same
reason :)
Comment 3 Dirk-Jan C. Binnema nokia 2005-11-14 16:01:49 UTC
(In reply to comment #2)

Well, you don't have to convince me :-) I will discuss this with the l10n-people. 

For some non-English-speaking users at least it's better to have a generic
localized 'Delivery failed' instead of some (for them) undecypherable English
term, which might include technical terms they wouldn't even understand if they
did speak English. The mere showing of such language will frighten such people.
But I guess you are not one of them :-)
Comment 4 David Woodhouse (reporter) 2005-11-14 16:12:39 UTC
Even if I _was_ one of the people who would be frightened by an error message
which actually explained the problem, it wouldn't matter. If I was one of those
people, I wouldn't read anything after the word 'error' anyway -- I'd just take
it to my sysadmin, who is going to be rightly upset if it doesn't actually give
_him_ any useful information.

To avoid confusing users in the case where everything is working makes a certain
amount of sense. But in the case of an _error_ it's daft to hide the error
"because it might confuse the user". Because that user is going to have to seek
help anyway.
Comment 5 Dirk-Jan C. Binnema nokia 2005-11-14 16:26:50 UTC
(In reply to comment #4)

Sure - only most of the 770-users don't have a sysadmin. I agree it's nice to
see the real error message somehow, but maybe not in the user interface.
Comment 6 David Woodhouse (reporter) 2005-11-14 16:34:17 UTC
If the users don't have a sysadmin then it's even more important for them to
see
the actual error. Otherwise you're just making it harder for them to work out
what's wrong, surely?

I was able to work out what was happening because I could watch the logs on the
server, or run tcpdump, and see what actually happened. If I wasn't the
sysadmin, and didn't have access to a sysadmin, then I'd have been screwed. 

It's not just 'nice to see the real error message'. If there's a problem and
it's stopping me from sending mail, it's _imperative_ to see the _real_ error
message. It doesn't matter if it'll scare me -- it's the only hint I have
regarding how to make it work.

If you're not going to show the real error message, you might as well just
print
a message saying "You are unable to send mail. We don't want to tell you why.
Go
away".
Comment 7 Frank 2006-01-25 05:25:05 UTC
So has this been resolved?
I get the same error and would like to know what path I should take to correct
the settings or whatever so that I can send mail.
Comment 8 David Woodhouse (reporter) 2006-01-25 05:37:09 UTC
At the moment I believe it hasn't been resolved. The only way you can find out
what the actual error was is to use tcpdump, or ask your sysadmin to look in the
server's logs to see what happened. The email client on the 770 won't tell you.

Or you could switch to pine... http://david.woodhou.se/maemo-pine.html :)
Comment 9 Dirk-Jan C. Binnema nokia 2006-01-25 10:36:06 UTC
Well, the bug was made "RESOLVED - LATER", that does not mean it has been
FIXED.
It just means that we will consider it for some future version of the program.

I agree that the error messages are not very helpful to the experienced user,
but those are not the only ones using the 770. But we had that discussion
already (comment #1-#6), so we don't need to repeat that I guess.
Comment 10 David Woodhouse (reporter) 2006-01-25 11:52:17 UTC
The error messages are both incorrect and misleading, to _both_ the
inexperienced and the advanced user (and to anyone to whome the inexperienced
user turns for help). It would be better to just say "Error" and no more, rather
than to give an incorrect error message as we do at the moment. At least that
would only be uninformative, rather than actively misleading.

Whether we should report the actual error message from the SMTP server is one
question which is perhaps open to debate... but making up an error message
"Recipient not found on server" is blatantly wrong. Perhaps they should be split
into separate bugs?
Comment 11 Dirk-Jan C. Binnema nokia 2006-01-25 12:06:37 UTC
(In reply to comment #10)

David - good point; you're right about giving *wrong* error msgs of course; it
shouldn't be much of a problem anymore in this particular case though at least
in the mentioned EHLO/HELO-case, as the bug that caused in the error message in
the first place, was fixed. If you still see the bug with recent releases,
please let us know :-)
Comment 12 David Woodhouse (reporter) 2006-01-25 12:36:47 UTC
I presume I won't see bug #200, but I bet I could still trigger the incorrect
error message.

Refusal of an email message is _often_ deferred to the RCPT TO: stage. Many
people want to be more permissive for email sent to postmaster@, for example. So
an invalid sender may not be rejected at MAIL FROM: time -- only at RCPT TO:.

My servers do that too -- and again, the error message from the SMTP server will
clearly state that it is the _sender_ address at fault. But the osso-email
program will ignore that, and still tell the user 'Recipient not found on server'.
Comment 13 David Woodhouse (reporter) 2006-01-25 12:50:58 UTC
That last example is one where even the most non-technical user might benefit
from actually _seeing_ the error message from the SMTP server, by the way.
Because it's going to happen when the user mistypes their own address. 

For example, a server might give this response to the RCPT TO: command:

550 Verification failed for <bil@woodhou.se>

Even a user as naïve as my father ought to be able to look at that message and
realise he'd missed out an 'l' when entering his username. Unless, that is, the
error gets reported as 'Recipient not found on server'. :)
Comment 14 elmano carvalho 2007-06-27 17:53:18 UTC
(In reply to comment #9)
> Well, the bug was made "RESOLVED - LATER", that does not mean it has been
> FIXED.
> It just means that we will consider it for some future version of the program.
> 

Could someone verify if this bug still exist?
This bug has been filed over a year and a half now, and if this is obsolete,
then we need to close it.
Comment 15 Andre Klapper maemo.org 2008-09-01 16:40:26 UTC
Bug does not apply to Modest anymore, the email application nowadays used.
Closing this bug as WONTFIX to get rid of the deprecated LATER resolution.

Please file a new bug against Communication -> Mail if this still applies for
Diablo (4.1).