Closed
Bug 292765
Opened 20 years ago
Closed 6 years ago
SMTP access denied error messages appear attached to main mail window rather than the compose window that causes them
Categories
(MailNews Core :: Networking: SMTP, defect)
MailNews Core
Networking: SMTP
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: IDontUseMozillaAnyMore, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050401
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050401
If you attempt to send a message using a smtp account that refuses the
connection, say a blocked relay, the error message is displayed is attached to
the main mailnews window rather than the compose window where you clicked the
send button.
Reproducible: Always
Steps to Reproduce:
1. Setup an SMTP account for a server that will reject your attempt to send.
(any ISP server will generally do this as they are only accessable from their
own dialup/dsl connections). Try smtp.nildram.co.uk (assuming it's not your
ISP)
2. Compose a message and click send.
Actual Results:
The error message:
'An error occurred while sending mail. The mail server responded:
<test@test.test>: recipient address rejected: relay access dnied. please verify
that your email address is correct in your mail preferences and try again'
is displayed attached to the main mail news window.
Expected Results:
The message should be attached to the message you are attempting to send.
Reporter | ||
Comment 1•20 years ago
|
||
Changing product to core (now I know it's there!)
Component: MailNews: Main Mail Window → Networking: SMTP
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
Updated•20 years ago
|
Summary: SMTP access denyed error messages appear attached to main mail window rather than the compose window that causes them → SMTP access denied error messages appear attached to main mail window rather than the compose window that causes them
Related to bug 262753 and Suite bug 220851?
Comment 3•19 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Reporter | ||
Comment 4•19 years ago
|
||
Yes, this is still happening. Do not remove this bug.
Reporter | ||
Comment 6•18 years ago
|
||
Still there in 1.5 release
Comment 7•17 years ago
|
||
This is still an issue on trunk (and 2.0.x also). I'm trying to wade through the variations, but some alerts pop-up off the main window, some pop up off the compose window. I'm attempting to stumble my way through this, but any suggestions appreciated.
Comment 8•17 years ago
|
||
If you have an SSL/TLS related error, that hangs off the main window, but the sending process will also throw up a more basic error that hangs off the compose window (from nsMsgPrompts). I haven't found where the SSL/TLS messages come from yet.
Comment 9•17 years ago
|
||
I've figured out that the SMTP code calls through the nsPrompt->Alert() directly, and gets the dialog box hung off the correct parent (on trunk). The security problems call through nsNSSIOLayer->displayAlert() and use a proxy to get a prompt, and these get hung off the main window. I'm quite confused in how the parent window is set or figured out - my C++ skills are not that good.
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 10•15 years ago
|
||
(In reply to comment #9)
> I've figured out that the SMTP code calls through the nsPrompt->Alert()
> directly, and gets the dialog box hung off the correct parent (on trunk). The
> security problems call through nsNSSIOLayer->displayAlert() and use a proxy to
> get a prompt, and these get hung off the main window. I'm quite confused in how
> the parent window is set or figured out - my C++ skills are not that good.
enough to confirm?
Reporter | ||
Comment 11•15 years ago
|
||
Surely simply seeing it happen is enough to confirm the bug. Anyone can do this by simply changing their SMTP server to a bad address and trying to send a message. Can it really take more then 4 years to confirm this?
Comment 12•15 years ago
|
||
(In reply to comment #11)
> Surely simply seeing it happen is enough to confirm the bug. Anyone can do this
> by simply changing their SMTP server to a bad address and trying to send a
> message.
FWIW, I can reproduce this, but I didn't confirm because part of the implied question to those more knowledgeable than me is a) whether the code previously identitified by chris' great research is in fact the cause and b) whether this is a dupe
> Can it really take more then 4 years to confirm this?
when there aren't many people looking at these, and some of them don't have privileges to confirm and a variety of other reasons, sure, absolutely it can take that long.
Comment 13•14 years ago
|
||
Nikolay, do you figure that bug 262753 and this are likely the same (or have the same fix)?
Depends on: 262753
Comment 14•14 years ago
|
||
W/o lookin into code it's difficult to say. Password dialog is always been modal as far I remember and there some changed made during 3.0 development in it. My guess it's still different bugs.
Comment 15•14 years ago
|
||
Since when is it necessary to find the bug in the source code before
confirming it?
AFAIK, after working on Mozilla code from day 1 in 1998, a bug is confirmed
when it can be reproduced, or at least witnessed, by more than one person,
and it is deemed by those who design or maintain the product to not be the
desired/expected behavior.
Now, the first of those two criteria is clearly met. I guess we're waiting
for someone who works on TBird to say "Yeah, that's a bug". Can that really
take over 5 years? (Ob answer: Of course! This is TBird after all.)
See also bug 388242. Like this bug, that bug reports a dialog that is
modal to the wrong window, modal to the main mail window, rather than to
the compose window where it belongs. It probably has the same cause as this
bug, but it's a youngster, being merely 3 years old. Needs to age more. :(
Comment 16•14 years ago
|
||
I think Nikolay was speaking only of the comparison and whether the bugs are the same, not about whether this is confirmable. But the question is relevant because we prefer not to confirm dups.
As for the behavior, I can't speak for Nikolay, I rarely confirm things that I didn't test, and I didn't. Please confirm issues or dupe as you think appropriate - you certainly have grasp of the issues and it's within your bz privileges.
Comment 17•14 years ago
|
||
I've just answer Wayne question and did not try to reproduce it. Now I did.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: PowerPC → All
Comment 19•6 years ago
|
||
Wayne, I tried producing several different errors while sending and the pop-ups I see are all over top of the write window and not over the main window. So maybe this is fixed or I'm missing something. Also, can't duplicate the dup bug 770214 (put quotes around the email address to cause the problem).
Comment 20•6 years ago
|
||
Nikolay do you agree this is gone?
What about bug 262753?
Flags: needinfo?(shopik)
Keywords: qawanted
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•