Bug 12957

Try a wireshark trace in each case.  Ifd it's the same version of TB and the same POP server, it's got to be a TCP/firewall issue with a lousy error message.

Unless there really *is* a difference in the profiles.  In any case, a TCP trace will show the cause.

CC: (none) => ftg

Thanks Frank,
I never used wireshark before, but a quick read and tests on both installations indicate that in Cauldron nothing is transmitted or received, whereas in Mga4 I can see the transaction take place correctly.

To test I did:
1. Start dumpcap as root
2. Hit send in TB
3. CTRL/c to stop capture
4. Run wireshark as root and open capture file.

I have only one TB profile in my /home which is used for both systems.
Both systems have firewall disabled.

All other ethernet traffic is visible on the interface in Cauldron e.g. irc, ssh (both of which I stopped while testing to avoid clutter)

So why is TB giving the error without even sending the request to the mail server I wonder - I thought the error message was too instant, as to be a real fail it would surely have to wait a timeout of at least a few seconds. The error message is instant on hitting send.

From what I can find ( http://forums.mozillazine.org/viewtopic.php?f=29&t=989095 ), this was some sort of TB change of behavior back in 2008.  That link and the mozilla bug report referenced by it give directions as to what to look for.  In addition to the GUI directions, they also reference the underlying prefs.js key involved.

If it's the same profile, then it has to be different TB versions, no ?

Also, see https://support.mozilla.org/en-US/kb/unable-to-authenticate-to-smtp-server

Well, thanks for searching. I too have been searching as I have several years worth of TB support mails stored here, but no joy yet.

I don't think those links of yours are relevant, as they appear to relate to an actual response from the mail server where a user/password is either wrong or not required. Also those are ancient relating to TB2/3.

My issue seems to be that there is nothing sent.

Also both versions are the same here:
Cauldron: thunderbird-24.3.0-1.mga5
Mga4:     thunderbird-24.3.0-1.mga4

I will try copying my profile into a Cauldron VM to test later, where I will be able to delete and re-create the SMTP account without breaking anything.
My profile is OK as it is in Mga4 and I don't want to break it.

This is very strange.

Getting back to basics, does the mailserver in fact require authentication ?  Do you have "Use name and password" checked ?  What port ? 

I tried to send mail through mailhost.zen.co.uk from a fresh cauldron user with a bogus address, and got a popup which I'll attach saying that you either have to be on the zen network or else authenticate with TLS.

Another possibility is that when I configured the mailserver in cauldron, it decided to use port 587 for outgoing SMTP.  Do you possibly have shorewall running, and is it possibly blocking port 587 ?

Created attachment 5029 [details]
Authentication popup

If it's of any help - my backup system has both mga4 and cauldron installed. I don't use a common /home but copied ~/.thunderbird from mga4 to cauldron, and TB in cauldron sends mail through my ISP without a problem. Both mga4 and cauldron have tb 24.3.

OK to answer your questions:
In Mga4 which works I am using password authentication transmitted insecurely.
If I switch to no authentication then I get:

An error occurred while sending mail. The mail server responded:  authentication required - Your email could not be sent. To fix this you must make a simple change to your email client (known as SMTP authentication). For advice visit http://www.bt.com/smtp.  Please verify that your email address is correct in your Mail preferences and try again.

As you can see my outgoing mail server is bt (my ISP) not zen (I use zen only for incoming).

It works fine with default port 587, however on reading the notes in the link above I have changed to the recommended SSL and port 465 with plain password. This still works OK in Mga4, but running the same profile in my regular Cauldron installation produces:

Sending of message failed.
The message could not be sent because connecting to SMTP server mail.btinternet.com failed. The server may be unavailable or is refusing SMTP connections. Please verify that your SMTP server settings are correct and try again, or contact the server administrator.

I am in another real Mga4 installation now, just updated from an Alpha (again using my regular /home).

It works, so I will update it to Cauldron now and see if it breaks TB.

My attempts in a VM went pear shaped as my master Cauldron VM did not have space for my 7GB TB profile!

Created attachment 5030 [details]
smtp settings

Something's awry here.  In your original post, the message clearly mentioned an SMTP (outbound) error against mailhost.zen.co.uk.  The attachment I posted suggests that that host either requires no authentication (if you're on the zen wire) or requires TLS authentication from outside the zen wire.

bt appears to require normal user/password authentication, so turning it off is pointless, and gives the error I would expect.  When you switch to SSL/465, the conection fails, indicating that bt doesn't support using port 465.  Again, no surprise.

The question is why under cauldron you're trying to connect to zen rather than bt for outbound SMTP.  I don't really understand how this could happen with the identical profile.  But if it *is* happening, it explains everything.  Your bt profile specifies userid/password, but zen doesn't appear to support that (either nothing or TLS).  So if you're trying to use the bt authentication profile on the zen host, I'd expect you to get exactly what you originally posted.

Well it works OK in that updated system, but my regular Cauldron in daily use still fails and there is no sign of any traffic to the server when attempting to send.

@Jim - thanks for checking - it's really weird, but it has to be some service/external program that TB uses that is broken on this Cauldron install.
It is not TB itself.
It is not my TB profile.

(In reply to Frank Griffin from comment #11)
> Something's awry here.  In your original post, the message clearly mentioned
> an SMTP (outbound) error against mailhost.zen.co.uk.  The attachment I
> posted suggests that that host either requires no authentication (if you're
> on the zen wire) or requires TLS authentication from outside the zen wire.
> 
Strange - I can't explain why it was trying to contact zen on that occasion, however that is not the case in all the subsequent testing and is a red herring.

> bt appears to require normal user/password authentication, so turning it off
> is pointless, and gives the error I would expect.  When you switch to
> SSL/465, the conection fails, indicating that bt doesn't support using port
> 465.  Again, no surprise.

No it does not fail using SSL/465 and this is the bt recommended setting.

> 
> The question is why under cauldron you're trying to connect to zen rather
> than bt for outbound SMTP.  I don't really understand how this could happen
> with the identical profile.  But if it *is* happening, it explains
> everything.  Your bt profile specifies userid/password, but zen doesn't
> appear to support that (either nothing or TLS).  So if you're trying to use
> the bt authentication profile on the zen host, I'd expect you to get exactly
> what you originally posted.

Yes I agree, but I m only using BT for outgoing - I really can't explain that message, but if you look at the subsequent messages in e.g. #9 they refer to BT.

It does work in the system I upgraded from Mga4 to Cauldron, so it's not a settings or profile issue and I do apologize for the error message in the first post, probably copied during my attempts to diagnose the issue.

This has to be a broken routine in some TCP plumbing in this one installation, as it's sending nothing, receiving nothing yet complaining about the reply!

I'm losing track here.

You have an MGA4 system that works with your TB profile, and if you upgrade it to cauldron, it still works.  But you have a freshly-installed cauldron system where it fails.  

Can we get the exact failure message again ?  I'm suspect of the original post since the hostname didn't match, and following comment#9 the only claimed error here is that SSL/465 works in MGA4 but not in cauldron, and it fails with no error message but a failed connect.  This could result from shorewall blocking the outgoing connect.

If you leave the authentication set to the same settigs (userid/password) that work under MGA4 for BT, exactly what is the result when you try them in cauldron ?

(In reply to Frank Griffin from comment #14)
> I'm losing track here.
> 
Not surprised ;)

> You have an MGA4 system that works with your TB profile, and if you upgrade
> it to cauldron, it still works. 

Yes

> But you have a freshly-installed cauldron
> system where it fails.  
>

No - it's my rolling system which is always Cauldron which I use daily - if it breaks badly I revert to stable until it gets fixed, using the same /home always.

> Can we get the exact failure message again ?

"Sending of message failed.
The message could not be sent because connecting to SMTP server mail.btinternet.com failed. The server may be unavailable or is refusing SMTP connections. Please verify that your SMTP server settings are correct and try again, or contact the server administrator."

> I'm suspect of the original
> post since the hostname didn't match, and following comment#9 the only
> claimed error here is that SSL/465 works in MGA4 but not in cauldron, and it
> fails with no error message but a failed connect.  This could result from
> shorewall blocking the outgoing connect.

[baz@jackodesktop ~]$ ps aux | grep [s]hore
[baz@jackodesktop ~]$

[root@jackodesktop baz]# systemctl status shorewall.service
shorewall.service - Shorewall IPv4 firewall
   Loaded: loaded (/usr/lib/systemd/system/shorewall.service; disabled)
   Active: inactive (dead)

In #9 I was testing with my 'Main' Mga4 and my 'Main' Cauldron.
Since then I took another install of Mga4 which worked OK (with SSL/465) and upgraded it to a new Cauldron where it also works OK.
> 
> If you leave the authentication set to the same settigs (userid/password)
> that work under MGA4 for BT, exactly what is the result when you try them in
> cauldron ?

As above, it works in the newly upgraded one but not in my rolling install (it's been my Cauldron since pre Mga3) iirc.

Out of interest I set up kmail in the newly upgraded Cauldron.

It worked fine and auto detected the correct bt settings (SSL/465/plain PW)

In my regular rolling Cauldron using the same /home (so same settings) it fails with:

Failed to transport message. mail.btinternet.com: Connection refused.

So this is a mail transport problem, not specific to Thunderbird.

OK, this is starting to make more sense.  Do you have any other problems on this system getting to the external internet ?  Other hosts ?

"Connection refused" gotten immediately usually means that the host is reachable but not listening on that port.  Maybe use nmap or telnet to probe other ports, e. g.

  nmap mail.btinternet.com -p [110|465|587|25]
or
  telnet mail.btinternet.com [110|465|587\25]

[root@jaglap ~]# nmap btinternet.com -p 465

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-08 09:12 EST
Nmap scan report for btinternet.com (213.123.20.90)
Host is up (0.11s latency).
rDNS record for 213.123.20.90: www.btinternet.com
PORT    STATE    SERVICE
465/tcp filtered smtps

Nmap done: 1 IP address (1 host up) scanned in 2.21 seconds

[root@jaglap ~]# telnet mail.btinternet.com 465
Trying 65.20.0.43...
Connected to mail.btinternet.bt.lon5.cpcloud.co.uk (65.20.0.43).
Escape character is '^]'.
^]
telnet> quit
Connection closed.

As you can see, it's reachable from my system.  See what you get.

(In reply to Frank Griffin from comment #17)
> OK, this is starting to make more sense.  Do you have any other problems on
> this system getting to the external internet ?  Other hosts ?

Not that I am aware of.

> 
> "Connection refused" gotten immediately usually means that the host is
> reachable but not listening on that port.  Maybe use nmap or telnet to probe
> other ports, e. g.
> 
>   nmap mail.btinternet.com -p [110|465|587|25]
> or
>   telnet mail.btinternet.com [110|465|587\25]
> 
> [root@jaglap ~]# nmap btinternet.com -p 465
> 
> Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-08 09:12 EST
> Nmap scan report for btinternet.com (213.123.20.90)
> Host is up (0.11s latency).
> rDNS record for 213.123.20.90: www.btinternet.com
> PORT    STATE    SERVICE
> 465/tcp filtered smtps
> 
> Nmap done: 1 IP address (1 host up) scanned in 2.21 seconds

[baz@jackodesktop ~]$ nmap mail.btinternet.com -p 465

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-08 16:08 GMT
Nmap scan report for mail.btinternet.com (65.20.0.43)
Host is up (0.020s latency).
rDNS record for 65.20.0.43: mail.btinternet.bt.lon5.cpcloud.co.uk
PORT    STATE  SERVICE
465/tcp closed smtps

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds

So for you it's 'filtered' for me it's 'closed'.

> 
> [root@jaglap ~]# telnet mail.btinternet.com 465
> Trying 65.20.0.43...
> Connected to mail.btinternet.bt.lon5.cpcloud.co.uk (65.20.0.43).
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
> 

[baz@jackodesktop ~]$ telnet mail.btinternet.com 465
Trying 65.20.0.43...
telnet: connect to address 65.20.0.43: Connection refused

Hmm not sure what that means. (I tried as root too but didn't really think that was intentional on your part)

> As you can see, it's reachable from my system.  See what you get.

From Mga4:

[baz@jackodesktop ~]$ nmap mail.btinternet.com -p 465

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-08 16:26 GMT
Nmap scan report for mail.btinternet.com (65.20.0.43)
Host is up (0.022s latency).
rDNS record for 65.20.0.43: mail.btinternet.bt.lon5.cpcloud.co.uk
PORT    STATE SERVICE
465/tcp open  smtps

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds

[baz@jackodesktop ~]$ telnet mail.btinternet.com 465
Trying 65.20.0.43...
Connected to mail.btinternet.com.
Escape character is '^]'.
^[
Connection closed by foreign host.
[baz@jackodesktop ~]$

Maybe this is more useful:

From non-working Cauldron:

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-08 17:28 GMT
Nmap scan report for mail.btinternet.com (65.20.0.43)
Host is up (0.023s latency).
rDNS record for 65.20.0.43: mail.btinternet.bt.lon5.cpcloud.co.uk
Not shown: 996 filtered ports
PORT    STATE  SERVICE
22/tcp  closed ssh
80/tcp  closed http
110/tcp open   pop3
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 22.95 seconds

#-----------------------------------------------------------
From working Cauldron:

[root@localhost baz]# nmap -sS mail.btinternet.com

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-08 17:46 GMT
Nmap scan report for mail.btinternet.com (65.20.0.43)
Host is up (0.041s latency).
rDNS record for 65.20.0.43: mail.btinternet.bt.lon5.cpcloud.co.uk
Not shown: 994 closed ports
PORT    STATE SERVICE
25/tcp  open  smtp
110/tcp open  pop3
465/tcp open  smtps
587/tcp open  submission
993/tcp open  imaps
995/tcp open  pop3s

Nmap done: 1 IP address (1 host up) scanned in 4.30 seconds

Filtered means that the nmap probes just get dropped off the end of the earth, whether the port is open or not.  Closed means that the remote stack shut you down with a RST.  Somebody doesn't like your failing system.

Can you do an ifconfig to see what IP address is being used by a working system and what IP address is being used by the failing system ?

Then, reconfigure the failing system to use the working system's IP address as a fixed IP and supply the correct gateway address and DNS.  Then try it again.  If it works, then there's something about the other IP that rubs them the wrong way.

Both are set up the same:
Fixed IP 192.168.1.65
Gateway 192.168.1.254
DNS1  8.8.8.8
DNS2  8.8.4.4

Failing system:

[root@jackodesktop baz]# ifconfig
eth0      Link encap:Ethernet  HWaddr 90:2B:34:35:6D:2F  
          inet addr:192.168.1.65  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::922b:34ff:fe35:6d2f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23788 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:74274873 (70.8 MiB)  TX bytes:1837385 (1.7 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:103 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:9072 (8.8 KiB)  TX bytes:9072 (8.8 KiB)

Working dystem:

[root@localhost baz]# ifconfig
enp2s0    Link encap:Ethernet  HWaddr 90:2B:34:35:6D:2F  
          inet addr:192.168.1.65  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::922b:34ff:fe35:6d2f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:1281 (1.2 KiB)  TX bytes:5040 (4.9 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:436 errors:0 dropped:0 overruns:0 frame:0
          TX packets:436 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:26160 (25.5 KiB)  TX bytes:26160 (25.5 KiB)

I just noticed that the failing system is using the old 'eth0' rather than 'enp2s0' I wonder if that is relevant?

(In reply to Barry Jackson from comment #23)
> I just noticed that the failing system is using the old 'eth0' rather than
> 'enp2s0' I wonder if that is relevant?

Shouldn't be visible at the remote end

OK, it's not the IP address or even the MAC address (since I notice that it's the same NIC in both cases), and that also means that it's not a case of two systems being up with the same IP.

That leaves some differing behavior in the stacks.

1) Have you updated the failing system unconditionally, i. e. urpmi --auto-select compared to the MGA4 upgrade ?  In other words, are there any known software differences between the two ?

2) Are they running the same kernel ?

3) If you've been continuously updating the failing system, you should have a range of older kernels available.  Can you see if you get the same failure with them ?

4) Are there any differences in /etc/sysctl.conf having to do with network handling ?

Resolved - finally after not using that system for several weeks the penny finally dropped.

Some time ago I imported Peerguardian and during testing the package I installed it, then forgot all about it until today, as it sits very silently in the background without any graphical interface/system tray icon etc.

It is an IP blocker /o\

systemctl stop pgl.service
fixed my mail issue.

Thought that I had better let you know (with head in hands ;)

Many thanks for your efforts, but as you will appreciate none of the diagnostics shed any light at all, and that package did not catch my eye when I was searching for system differences.

Cheers,

Barry

closing as invalid

Status: NEW => RESOLVED
Resolution: (none) => INVALID

No prob.  Interesting exercise !