Closed Bug 197172 Opened 21 years ago Closed 21 years ago

Sending of message fails with some SMTP servers

Categories

(MailNews Core :: Networking: SMTP, defect)

Product:
MailNews Core
Component:
Networking: SMTP
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hsi, Assigned: mscott)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

I installed binary version from ftp.mozilla.org:
-rw-r--r--  1 22  22  14454243 Mar 12 15:53  mozilla-i686-pc-linux-gnu-sea.tar.gz
on SuSE Linux 8.1 and SuSE Linux 8.2 Beta 3. But same problems are with Mozilla
1.3 beta versions

With 8.1 sending mails with SMTP works fine but sending with 8.2 Beta 3 will
fail with some SMTP servers (I do have several mail accounts).

"Sending of messages failed.
The message could not be sent because connecting to SMTP server <servername>
failed. The mail server may be unavailable or is refusing SMTP connections.
Please verify that your SMTP server setting is correct an try again, or else
contact your network administrator."

Since I do use the same settings (same .mozilla directory) under 8.1 and 8.2 I'm
sure that the problem isn't related to the SMTP server settings of mozilla).

I do think there is a compatibility problem - SuSE 8.2 Beta 3 uses gcc 3.3 and
glibc 2.3.2

Reproducible: Always

Steps to Reproduce:
1. install mozilla 1.3 on SuSE 8.2 Beta 3 or later
2. try to send mails to several SMTP servers (I think the SMTP server here is
Postfix - how can I check this in detail - with telnet?)

Actual Results:  
I got the error message named above - mail isn't sent.

Expected Results:  
send the mail
Try to look at the SMTP log. See
http://mozilla.org/quality/mailnews/mail-troubleshoot.html#smtp for details.
SMTP-Log will only contain:
  16384[807e6e8]: SMTP Connecting to: <name of mail server>
nothing else.
Can you get through OK to the mail-server via telnet or other mail apps?
I can sent mail with Mozilla 1.2.1 built for SuSE 8.2 Beta 3 and with Mozilla
1.2.1 binary from ftp.mozilla.org on SuSE 8.2 Beta 3 but cannot with Mozilla 1.3
i wondered if this was on two different machines sinec you also mentioned a SuSE
8.1 installation. (In which case the hosts file could differ)
I do have two different partitions one with SuSE 8.1 one with 8.2 Beta 3.

Believe in me - it's not a problem of the hosts file or any other
misconfiguration of the network because I do have Mozilla 1.2.1 and Mozilla 1.3
on the same 8.2 Beta 3 partition - with 1.2.1 it works, with 1.3 it doesn't work.
Is it the same SMTP server that works with 1.2.1 and fails with 1.3?
Does the bug also occur if you set up a fresh user profile for Mozilla?
Yes, it's the same SMTP server and it does work under SuSE 8.1 with 1.3.

I created a new (fresh) profile as well - same behavior.
Severity: critical → normal
Do you have any mail related addons for Mozilla installed? (Enigmail or other)
Yes, normally I do have installed Enigmail.

But installed Mozilla 1.3 (now final) and a fresh Profile without Enigmail or
any other Plugin on a fresh SuSE 8.2 Beta 3 with a new user home. Same Problem.
OK, I found a workaround: entering IP address instead of DNS of SMTP server will
help. One possibility could be IPv6 support in SuSE 8.2 - does Mozilla from
Version 1.3 support IPv6 as well (we have a local network - where the SMTP
server is located as well - maybe with IPv6 as well)?

If I try to ping the SMTP server with DNS host name resolution will work fine.
Host resolution of IMAP/POP-Server will work as well.
OK, tested with a guy who does know a little bit more than me about this topic.

We found out that Mozilla will make a DNS lookup and will get first an IPv6
address and after that a IPv4 address (see log):

14:45:07.532173 10.10.100.192.32814 > 10.10.0.1.53:  37911+ AAAA?
mailman.localnet.de. (33) (DF)
14:45:07.533983 10.10.0.1.53 > 10.10.100.192.32814:  37911* 2/7/13 CNAME
Fourier.localnet.de., AAAA 2001:780:101:a00:200:1cff:feb5:5068 (503)
14:45:07.544020 10.10.100.192.32814 > 10.10.0.1.53:  37912+ A? mailman.localnet.de.
(33) (DF)
14:45:07.546561 10.10.0.1.53 > 10.10.100.192.32814:  37912* 2/7/13 CNAME
Fourier.localnet.de., A 10.10.129.71 (491)

But it seems that if Mozilla will get an IPv6 address it will do nothing.

I was told this is not a normal DNS request - normally you should get only IPv4
address but if you do the request mozilla does (AAAA) you will get IPv6
addresses as well.

So maybe the problem is that mozilla will request IPv6 addresses but cannot
handle them in the right way?
additional info:
I do have a problem with some internal http-addresses as well. If I call a
machine: mailman.localnet.de mozilla will seek "connecting to ..." and after
some seconds it will show "Done." but the page will not have been loaded.

The log above is from such a http call.
I can remember a bug (which is resolved) where Mozilla shows "Document contains
no data" if the http-server was reachable via IPv6 but the HTTP-Server was 
not IPv6 aware. So Mozilla never tried the IPv4 address. This problem was
between 1.2.1 and 1.3 final.
In glibc-versions before 2.3 the linux resolver didn't ask for AAAA addresses but
if you told it in /etc/nsswitch.conf to do, you had the same behaviour.
Now with glibc 2.3 it seems to be the standard behaviour of the glibc always to
ask first for an AAAA address. It's possible that Mozilla tries to connect via
IPv6 but the MTA doesn't listen on this address and Mozilla stops again without
trying the IPv4 address.
The old bug was #193120
Blocks: IPv6
Any news on that bug? Status is still UNCONFIRMED
it seems that this bug is fixed with bug #199173
I can connect via NNTP and other protocols to the IPv6 hosts.
I think this bug can be closed as FIXED.
Reporter, this is probably fixed now. Can you still reproduce this? If not, I
will resolve this bug.
Yes, it's fixed now
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.