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)

defect
Not set
normal

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.
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
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?
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/
Yes, this is still happening. Do not remove this bug.
gone in 1.5 or current trunk?
Assignee: mail → nobody
Still there in 1.5 release
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.
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.
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.
Keywords: qawanted
QA Contact: networking.smtp
Product: Core → MailNews Core
(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?
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?
(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.
Nikolay, do you figure that bug 262753 and this are likely the same (or have the same fix)?
Depends on: 262753
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.
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. :(
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.
I've just answer Wayne question and did not try to reproduce it. Now I did.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: PowerPC → All

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).

Nikolay do you agree this is gone?

What about bug 262753?

Flags: needinfo?(shopik)
Keywords: qawanted

Yeah looks like gone now

Flags: needinfo?(shopik)
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.