Problem sending email with Betterbird/Thunderbird

English Network/Internet
1

Hi,

I have been unable for the last few days to send emails (SMTP, 465) with either Betterbird or Thunderbird. This is happening on my desktop using Leap 15.6. I CAN receive emails (POP, 995). The message returned when trying to send an email is AUP#EML-005 which relates to filtering. No filter is applied anywhere, I checked with my ISP and also spamhaus and nothing is blocked. The message is unrelated to my problem and is probably not relevent.

The programs used are:

DESKTOP
=======
### Betterbird
140.4.0esr-bb13 (64 bits)
www.betterbird.eu
betterbird-140.4.0esr-bb13.fr.linux-x86_64.tar.xz
installed under /home/marc/bin/betterbird
###

### MozillaThunderbird
140.3.0-150200.8.239.1
update-sle (15.6)
http://cdn.opensuse.org/update/leap/15.6/sle?mediahandler=curl2
###

### mailx
12.5-150600.16.3
repo-oss (15.6)
http://cdn.opensuse.org/distribution/leap/15.6/repo/oss?mediahandler=curl2

LAPTOP
======
### MozillaThunderbird
140.3.0-150200.8.239.1
update-sle (15.6)
http://cdn.opensuse.org/update/leap/15.6/sle?mediahandler=curl2
###

NOTE: The profiles where not mixed while doing tests, meaning that a backup was made prior to using a different version of the MUA (140.4.0esr vs 140.3.0).

Using the webmail interface of my ISP, I can send AND receive emails. I can also send emails using mailx from my desktop.

#!/bin/bash

echo "Message has been delivered" > body.txt

/usr/bin/mailx -n -vvv \
                           -S from="<MY EMAIL>" \
                           -S sendwait \
                           -S smtp="smtps://smtp.<MY ISP>:465" \
                           -S smtp-auth-user="<MY EMAIL>" \
                           -S smtp-auth-password="<MY PASSWORD>" \
                           -S smtp-auth="login" \
                           -S ssl-verify="warn" \
                           -s "This is a mailx test" \
                           -c <MY OTHER EMAIL>@protonmail.com \
                           <MY EMAIL> < body.txt

rm body.txt

exit 0

The problem is not present on my laptop and is also using Leap 15.6. The credentials are the same on both my desktop and laptop. The difference beeing that my laptop is a little bit behind on the updates. Which lead me to believe that an update “might” be causing the problem on my desktop.

On my desktop, creating a new user, or a new profile in either Betterbird or Thunderbird, does not change anything. The problem remains.

My repos are all standard.

marc@tokra:~/temp $ LANG=C zypper lr -d
#  | Alias                           | Name                          | Enabled | GPG Check | Refresh | Keep | Priority | Type   | URI                                                                                  | Service
---+---------------------------------+-------------------------------+---------+-----------+---------+------+----------+--------+--------------------------------------------------------------------------------------+---------
 1 | Double_Commander                | Double Commander              | No      | ----      | ----    | -    |   99     | rpm-md | http://download.opensuse.org/repositories/home:/Alexx2000/openSUSE_Leap_15.5/        | 
 2 | NVIDIA:repo-non-free            | repo-non-free (15.6)          | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://download.nvidia.com/opensuse/leap/15.6                                       | NVIDIA
 3 | marc                            | marc                          | Yes     | ( p) Yes  | Yes     | -    |   99     | rpm-md | dir:/home/marc/raidz2/0_programmes/0_mes_packages/0_localrepo/                       | 
 4 | openSUSE:repo-non-oss           | repo-non-oss (15.6)           | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://cdn.opensuse.org/distribution/leap/15.6/repo/non-oss?mediahandler=curl2       | openSUSE
 5 | openSUSE:repo-non-oss-debug     | repo-non-oss-debug (15.6)     | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/distribution/leap/15.6/repo/non-oss?mediahandler=curl2 | openSUSE
 6 | openSUSE:repo-openh264          | repo-openh264 (15.6)          | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Leap?mediahandler=curl2                 | openSUSE
 7 | openSUSE:repo-oss               | repo-oss (15.6)               | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://cdn.opensuse.org/distribution/leap/15.6/repo/oss?mediahandler=curl2           | openSUSE
 8 | openSUSE:repo-oss-debug         | repo-oss-debug (15.6)         | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/distribution/leap/15.6/repo/oss?mediahandler=curl2     | openSUSE
 9 | openSUSE:repo-oss-source        | repo-oss-source (15.6)        | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/source/distribution/leap/15.6/repo/oss?mediahandler=curl2    | openSUSE
10 | openSUSE:update-backports       | update-backports (15.6)       | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://cdn.opensuse.org/update/leap/15.6/backports?mediahandler=curl2                | openSUSE
11 | openSUSE:update-backports-debug | update-backports-debug (15.6) | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/update/leap/15.6/backports_debug?mediahandler=curl2          | openSUSE
12 | openSUSE:update-non-oss         | update-non-oss (15.6)         | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://cdn.opensuse.org/update/leap/15.6/non-oss?mediahandler=curl2                  | openSUSE
13 | openSUSE:update-non-oss-debug   | update-non-oss-debug (15.6)   | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/update/leap/15.6/non-oss?mediahandler=curl2            | openSUSE
14 | openSUSE:update-oss             | update-oss (15.6)             | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://cdn.opensuse.org/update/leap/15.6/oss?mediahandler=curl2                      | openSUSE
15 | openSUSE:update-oss-debug       | update-oss-debug (15.6)       | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/update/leap/15.6/oss?mediahandler=curl2                | openSUSE
16 | openSUSE:update-sle             | update-sle (15.6)             | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://cdn.opensuse.org/update/leap/15.6/sle?mediahandler=curl2                      | openSUSE
17 | openSUSE:update-sle-debug       | update-sle-debug (15.6)       | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/update/leap/15.6/sle?mediahandler=curl2                | openSUSE
18 | opensuse-guide                  | libdvdcss                     | No      | ----      | ----    | -    |   99     | rpm-md | https://opensuse-guide.org/repo/openSUSE_Leap_15.6/                                  | 
19 | packman                         | Packman                       | Yes     | (r ) Yes  | Yes     | -    |   90     | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.6/                   | 
20 | sauerland                       | Sauerland                     | No      | ----      | ----    | -    |   99     | rpm-md | http://download.opensuse.org/repositories/home:/Sauerland:/qt4/openSUSE_Leap_15.6/   |

I have been trying a lot of things hoping to fix the problem but I failed. One thing that I tried was to downgrade quite a few packages to have the same versions installed on my laptop. I since then revert all the changes using zypper up.

Here are the informations relative to my desktop and my laptop:

DESKTOP                                                           LAPTOP
=======                                                           ======
Operating System: openSUSE Leap 15.6                              Operating System: openSUSE Leap 15.6
KDE Plasma Version: 5.27.11                                       KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0                                   KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12                                               Qt Version: 5.15.12
Kernel Version: 6.4.0-150600.23.73-default (64-bit)               Kernel Version: 6.4.0-150600.23.70-default (64-bit)
Graphics Platform: X11                                            Graphics Platform: X11
Processors: 16 × Intel® Core™ i9-9900KF CPU @ 3.60GHz             Processors: 4 × Intel® Core™ i5-3320M CPU @ 2.60GHz
Memory: 31.1 Gio of RAM                                           Memory: 11.5 Gio of RAM
Graphics Processor: NVIDIA GeForce GTX 750 Ti/PCIe/SSE2           Graphics Processor: Mesa Intel® HD Graphics 4000
Manufacturer: Gigabyte Technology Co., Ltd.                       Manufacturer: LENOVO
Product Name: Z390 AORUS MASTER                                   Product Name: <REDACTED>
                                                                  System Version: ThinkPad T530

As you can see, except for the kernel, they’re pretty much the same.

I saw this thread, Dovecot Postfix struggle to send e-mail. The problem could be the same even though the programs involved are different.

If you need any other infos, just let me know.

Hope that someone can help!

2

@balaffre:

First, welcome to the openSUSE Forums.

  • Given that, you can send e-Mail via the CLI, the graphical e-Mail clients are possibly not using a Port which your ISP requires.

Please double check, your ISP’s requirements with respect to the addresses of their SMTP and POP servers and, the IP Ports which they are using for those servers; plus, the IP Ports matched to the encryption being used for the e-Mail – TLS/STARTTLS or, SSL or, whatever.

If you’re reasonably comfortable with inspecting Network Traffic, you could try installing Wireshark and then, inspect the packets being exchanged between your e-Mail client and your ISP.

3

Try to set mailnews.smtp.loglevel to All and have a look at the Error Console:

4

@dcurtisfra:

Thanks for the welcome.

Sorry if i wasn’t clearer when i mentioned that my desktop was not able to send email and my laptop was. BOTH are using the same “everything”. Server, port, encryption, etc. Even with that, I cannot send emails.

The fact that when I try to send an email with my deskyop and i’m not even asked for my password tells me there is something wrong somewhere and it’s not in the configuration. This has been checked more than once.

The password has even been resetted at my ISP. My laptop had no problem connecting. Passwords where asked when I checking new emails and was also asked when I wanted to send an email.

On my desktop, I was asked for the password when I checked for new emails BUT sending an email gives me the error message, AUP#EML-005. I’m not even asked for the password even though the connection is accepted.

@marel:

This has already been tried a while ago and it errors out on AUP#EML-005. The “internal error” that preceed the code is rather cryptic to me.

Please see (I edited some infos):
https://paste.opensuse.org/pastes/d5653337db42

I tried strace, but it’s above my paygrade! :face_with_spiral_eyes:

Thank you for your help.

1 Like
5

mailnews.smtp: S : 501 EHLO xxxxxx internal error AUP#EML-005

Good info. I see your are not the only one triggering this error:

Impossible envoyer message depuis un mois.

Can you try also with port 587 and security = “None”.

This error code is AUP#EML-005 originating from your email provider, your provider seems to use the same software as the provider of hel1111.

That problem was eventually solved by resetting a router so that points you the Internet connection. Are the laptop (working) and the desktop (problem) connected the same way to the Internet?

What is good about your problem is that you can compare good versus bad. So you could compare the strace output, you could also share it via paste.opensuse.org, for a network problem strace output is not that helpful.

On the error code itself, AI can tell me that the mail server rejecting the email based on some form of policy or configuration, possibly related to an Acceptable Use Policy (AUP).

That makes sense to me, is your desktop using a VPN and the laptop not? Different IP nets?
Try running tracepath to the smtp server and compare the output with that for the laptop.

6

Thanks for the link but I already saw it while I was searching for a solution.

Port 587 just timeout.

Yes it’s the same provider. You are correct that the AUP is “Acceptable Use Policy”. In my case, I don’t think it’s related at all (but could it be?).

Both desktop and laptop are on the same network/subnet, 192.168.1.0/24 and are using wicked with a static IP (.13 and .109). I get my WAN IP address from my ISP by DHCP. The Cablemodem and router/firewall (pfSense) were restarted for good measure…

Both are configured to connect to my ISP for emails. The credentials, ports, etc are exactly the same.

I ran tracepath and both results came out identical. I also ran an strace using the option -e trace=%net as well as Wireshark listening on eth1 with a filter to watch for tcp.port=465. Nothing exciting to report. In fact, the most instructive informations are from the error console in Betterbird/Thunderbird.

When connecting to my ISP for emails, I need to supply (only once, …stored) my password to be able to access the POP server. Sending an email (SMTP), i’m never asked for a password (never stored, …obviously), and I sould be.

If you refer back to the image on susepaste, the client (me, C: EHLO [192.168.1.13]), although you cannot see it, is not sending the passord to the server because i’m not asked for it. hence the answer from the server, mailnews.smtp: S : 501 EHLO xxxxxx internal error AUP#EML-005. I doubt that an ISP can filter out on an internal address…

The “handshake” from my laptop as seen in the error console for Thunderbird:

NOTE: C: denote data from the Client, S: denote data from the Server.

mailnews.smtp: Connecting to smtp://<MY ISP>:465
mailnews.smtp: Connected
mailnews.smtp: S: 220 smtp.<MY ISP> <MY ISP> ESMTP server ready
mailnews.smtp: C: EHLO [192.168.1.109]
mailnews.smtp: S: 250-smtp.<MY ISP> hello [184.161.xxx.xxx], pleased to meet you
250-HELP
250-AUTH LOGIN PLAIN
250-SIZE 68500000
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 OK
mailnews.smtp: Possible auth methods: PLAIN,LOGIN
mailnews.smtp: Current auth method: PLAIN
mailnews.smtp: Authentication via AUTH PLAIN
mailnews.smtp: C: Logging suppressed (it probably contained auth information)
mailnews.smtp: S: 235 2.7.0 ... authentication succeeded
mailnews.smtp: Authentication successful.
mailnews.smtp: C: MAIL FROM:<MY EMAIL> SIZE=547
mailnews.smtp: S: 250 2.1.0 <MY EMAIL> sender ok
mailnews.smtp: MAIL FROM successful, proceeding with 1 recipients
mailnews.smtp: Adding recipient...
mailnews.smtp: C: RCPT TO:<MY EMAIL>
mailnews.smtp: S: 250 2.1.5 <MY EMAIL> recipient ok
mailnews.smtp: Total RCPTs during this connection: 1
mailnews.smtp: RCPT TO done. Proceeding with payload.
mailnews.smtp: C: DATA
mailnews.smtp: S: 354 OK
mailnews.smtp: Sending 547 bytes of payload
mailnews.smtp: S: 250 2.0.0 IArivZoPyD6EmIArjvEnxQ mail accepted for delivery
mailnews.smtp: Message sent successfully.
mailnews.smtp: Start 5 second QUIT timer

Unless someone can tell me what packages/programs/libraries are involved in detecting/asking/sending that a password is needed when someone wants to send an email, my next step will be to generate a list of packages installed on my desktop and on my laptop and work my way through to find what packages have a different version/release and check if that fix my problem by reverting back packages on my desktop.

Because of that, i’ll go back to my cage and be quiet for a couple of days. :nerd_face:

To conclude, I do not use a VPN and for the curious minds among you, I invite you to check:

VPN Company relationships

I have absolutly no relationships with these people. Do whatever you want with that information.

Thanks for any help!

7

Good to see the “handshake” from my laptop as seen in the error console for Thunderbird.

You shared the output for the desktop but only graphical, so for a good compare:

mailnews.smtp: Connecting to smtp://<MY ISP>:465
mailnews.smtp: Connected
mailnews.smtp: S: 220 smtp.<MY ISP> <MY ISP> ESMTP server ready
mailnews.smtp: C: EHLO [192.168.1.13]
mailnews.smtp: S: EHLO Hudjvk7674hCF internal error AUP#EML-005

So no, this has nothing to do with a password or not.

Given the other information you provided it looks to me the provider can not see the difference between your desktop and laptop and in that sense I would take the “Acceptable Use Policy” a bit more serious. A simple test should prove it wrong or wright: Direct after sending an email on the Desktop (that fails) try the Laptop.

8

The SMTP error code is “501” –

  • 501:
    The para­meters or argu­ments prov­ided are not vali­d.
    Revi­ew the reci­pient emai­l addr­ess and comm­and synt­ax.

Meaning, the SMTP server had an issue deciphering the message sent by your client.

  • Which is possibly the SMTP encryption between your client and the SMTP server.

Either an implementation issue at the e-Mail Client or, an implementation issue at the SMTP server.

Please check the e-Mail client version you have installed.
Does another e-Mail client also display this issue?

9

@dcurtisfra:

Thanks for giving me some ideas.

Your explaination makes sense but:

Desktop
Betterbird 140.5.0esr-bb14
Thunderbird 140.3.0-150200.8.239.1

NOTE: Betterbird updated from 140.4.0esr-bb13

BOTH programs can receive but cannot send emails.

Laptop
Betterbird 140.4.0esr-bb13 (new install, clean profile)
Thunderbird 140.3.0-150200.8.239.1

BOTH programs can receive AND send emails.

I did some research and here’s what I came up with.

This one should have been researched right from the start…
RFC 5321: Simple Mail Transfer Protocol

This one is related to my ISP (Communications Messaging Server)
Common SMTP Errors Returned by Email Delivery

As you can see, it points to a syntax error but in the case of Oracle, there are 3 possible causes which are all syntax errors anyway.

If there was a problem on either the client or the server, I would not be able to send emails on both computers.

The fact that one is able and the other one is not, makes me believe that an update caused the problem because the proper information is not sent/asked.

I even went back to check zypper’s history.

These are the packages that were downgraded to match what is on the laptop, but it didn’t fix my problem.

Is there any configuration file that would need changing?

root@ordi:~ # zypper ref && zypper lu
Repository 'update-backports (15.6)' is up to date.
Repository 'update-non-oss (15.6)' is up to date.
Repository 'update-oss (15.6)' is up to date.
Repository 'update-sle (15.6)' is up to date.
Repository 'repo-non-free (15.6)' is up to date.
Repository 'marc' is up to date.
Repository 'repo-non-oss (15.6)' is up to date.
Repository 'repo-openh264 (15.6)' is up to date.
Repository 'repo-oss (15.6)' is up to date.
Repository 'Packman' is up to date.
All repositories have been refreshed.
Refreshing service 'NVIDIA'.
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
S  | Repository        | Name                                   | Current Version               | Available Version            | Arch
---+-------------------+----------------------------------------+-------------------------------+------------------------------+-------
v  | update-sle (15.6) | cyrus-sasl                             | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | cyrus-sasl-crammd5                     | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | cyrus-sasl-digestmd5                   | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | cyrus-sasl-gssapi                      | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | cyrus-sasl-plain                       | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | krb5                                   | 1.20.1-150600.11.11.2         | 1.20.1-150600.11.14.1        | x86_64
v  | update-sle (15.6) | krb5-32bit                             | 1.20.1-150600.11.11.2         | 1.20.1-150600.11.14.1        | x86_64
v  | update-sle (15.6) | krb5-devel                             | 1.20.1-150600.11.11.2         | 1.20.1-150600.11.14.1        | x86_64
v  | update-sle (15.6) | libfreebl3                             | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | libfreebl3-32bit                       | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | libjavascriptcoregtk-4_0-18            | 2.48.5-150600.12.43.1         | 2.50.1-150600.12.48.3        | x86_64
v  | update-sle (15.6) | libjavascriptcoregtk-4_1-0             | 2.48.5-150600.12.43.1         | 2.50.1-150600.12.48.3        | x86_64
v  | update-sle (15.6) | libsasl2-3                             | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | libsasl2-3-32bit                       | 2.1.28-150600.7.6.2           | 2.1.28-150600.7.9.2          | x86_64
v  | update-sle (15.6) | libsoftokn3                            | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | libsoftokn3-32bit                      | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | libstdc++6                             | 14.3.0+git11799-150000.1.11.1 | 15.2.0+git10201-150000.1.3.3 | x86_64
v  | update-sle (15.6) | libstdc++6-32bit                       | 14.3.0+git11799-150000.1.11.1 | 15.2.0+git10201-150000.1.3.3 | x86_64
v  | update-sle (15.6) | libstdc++6-pp                          | 14.3.0+git11799-150000.1.11.1 | 15.2.0+git10201-150000.1.3.3 | x86_64
v  | update-sle (15.6) | libwebkit2gtk-4_0-37                   | 2.48.5-150600.12.43.1         | 2.50.1-150600.12.48.3        | x86_64
v  | update-sle (15.6) | libwebkit2gtk-4_1-0                    | 2.48.5-150600.12.43.1         | 2.50.1-150600.12.48.3        | x86_64
v  | update-sle (15.6) | mozilla-nss                            | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | mozilla-nss-32bit                      | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | mozilla-nss-certs                      | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | mozilla-nss-certs-32bit                | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | mozilla-nss-tools                      | 3.112-150400.3.57.1           | 3.112.2-150400.3.60.1        | x86_64
v  | update-sle (15.6) | qt6-network-tls                        | 6.6.3-150600.3.3.1            | 6.6.3-150600.3.6.1           | x86_64
v  | update-sle (15.6) | webkit2gtk-4_0-injected-bundles        | 2.48.5-150600.12.43.1         | 2.50.1-150600.12.48.3        | x86_64
v  | update-sle (15.6) | webkit2gtk-4_1-injected-bundles        | 2.48.5-150600.12.43.1         | 2.50.1-150600.12.48.3        | x86_64
root@ordi:~ #

I then directed my search to:
Bugzilla List: smtp

There are a lot of people having problems similar to mine but they’re mainly related to oauth2 (M$).

Quite frankly, I don’t know what else I can do :worried:

My quest continues :roll_eyes:

Thank you for your help!

10

You can contact your provider support.

11

Humm, this by itself is an aventure… :wink:

Level 1 tech are what I call Epsilons… In reference to Huxley’s “Brave New World” :rofl:

Anyway, what makes you think I didn’t contacted them? Yes, you’re right it was not explicitly mentionned in the OP, but…

In fact, I called them 2 days before I started this thread.

I spoke to someone (Level 3 tech) from my service provider and their conclusion was that the problem was on my side and I tend to agree with them considering all the information i’ve given up so far.

But hey, all is not lost. There is a new developpment!

I tried with claws-mail and guess what? IT WORKS! I can receive AND send emails from my desktop. Isn’t it wonderful?

I just need to find the program/library (?) that is responsible for miscommunicating the information to the server when using Betterbird/Thunderbird. That where i’m stuck at right now.

Any idea?

Thank you for your help.

12

â– â– â– â– â– â– â– â– â–  The connection is rejected by their server. While it may be triggered by something the client does it is quite reasonable to expect explanation, what the client does that their server does not like (and what AUP#EML-005 means). We have no way to guess it.

You can try to compare the full interaction - not only SMTP part, but really full, starting with TCP/IP setup, then SSL/TLS setup then SMTP handshake. Maybe you will be able to spot the common pattern (you have two good cases and two bad cases).

13

…yep, still here, been busy for the last 2 days trying to figure out what’s going on…

This might prove to be more difficult than you think!

According to them, it is related to spam filtering… but I really thing that is bogus. I haven’t seen AUP#EML-005 mentioned as spam related. Messages that are blocked by their anti-spam filter should be either AUP#EML-007 or AUP#EML-038 or ? There seems to be more than one error code for the spam filtering. So…

The 501 error seems to be the key.

This is what is sent (from my desktop):

mailnews.smtp: C: EHLO [192.168.1.13] SmtpClient.sys.mjs:655:19
mailnews.smtp: S: 501 EHLO JDBFvggTYD6Em internal error AUP#EML-005 SmtpClient.sys.mjs:452:17

This is what should be sent (from my laptop):

mailnews.smtp: C: EHLO [192.168.1.109]
mailnews.smtp: S: 250-smtp.<MY.ISP> hello [MY.WAN.IP], pleased to meet you

I recontacted my service provider and I spoke to someone else. I sent them the error console messages from my laptop and desktop as well as a Wireshark capture from my desktop. We’ll see. They told me to wait a few days before contacting them back if it’s not fixed.

My service provider is extremely reliable. Pratically no downtime or any other problems you might think of. With some exceptions I guess :roll_eyes:. I’ve been with them for the past 35 years (TV/Internet in 1995/Phone). BBS anyone? :stuck_out_tongue_winking_eye:

Betterbird and Thunderbird are using their own implementation of SMTP (smtpClient.sys.mjs) and for SSL/TLS, etc. it uses the Mozilla platform libraries as confirmed by Betterbird’s developper.

The TCP/IP stack is not the problem here. If it doesn’t work for one, it shoudn’t work for the other. My firewall rules haven’t changed for the past 12 years… On my desktop, I can send and receive email using claws-mail, I can even send emails using a VBox VM (openSUSE Leap 15.6, fully updated) installed on my desktop. I don’t know if KMail would work. Didn’t try, don’t care.

Since some of you are interrested by this thread, judging by the number of views, here’s an interresting read. See section: What are the steps of a TLS handshake?

What happens in a TLS handshake? | SSL handshake

In my case, it’s “crashing” when the server is trying to respond to my hello message, step 2 in the above link. What is making the server response go haywire. Beats me!

Next move? Maybe, possibly, eventually contacting Oracle… never know, I might get lucky :innocent:

Until next time…

1 Like
14

Some good debug done and yes more debug needed.

Some thoughts:

  • The laptop is using WiFi I presume, the desktop Ethernet. Try with the desktop on WiFi.
  • The TLS steps is interesting but that is not the problem otherwise you would not have come so far in the SMTP negotiation process.
  • Nice step, trying a 15.6 VM. Good to make a wireshark trace of desktop versus VM.
  • It could be something not in the SMTP transfer itself like there must be a POP3/IMAP exchange before the SMTP exchange
15

Problem fixed, Thanks every one… Okay bye!

Woo-hoo, that would be mean, no? :joy:

But more seriously, YES, the problem has been fixed.

The 501 error as nothing to do with the problem. The AUP#EML-005 is “sorta” responsible for my inability to send email.

My service provider decided it would be a good idea (not) to filter on non-mappable addresses [192.168.1.13] when their system decide that someone might be involve in sending and or receiving spam or is outside their AUP…

Here’s the explaination. I recently received an email from MY life insurance advisor that wanted to talk about how to manage retirement plan, etc. (definitely not there yet), and the guy thought it would be nice if he could reach a bunch of people at the same time… yep, 90 in CC!

I wrote him back with the nastiest email you could think of… :face_with_symbols_over_mouth: he then sent another message to the same 90 people… mentionning to be careful to not to click on unknown links and they would never ask for personal info in emails, etc, etc. He then wrote me (alone) an email saying he was sorry and people’s privacy was important to him blah, blah, blah… Sure, I believe you!

The consequence of this, I don’t know if it was the amount of people in the emails or my foul language, but the end result was that it was either considered as spam or against their AUP…

Sorry! :stuck_out_tongue_winking_eye:

Sooo, what is the fix? With the help of Betterbird’s developper we were, well, he was, in fact able to suggest a preference to add and instead of Betterbird sending and address literal ([192.168.1.13]), which is blocked, send the computers host name for the EHLO argument. This preference was created a long time ago for testing purpose.

See: 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)

Instead of sending and receiving this:

mailnews.smtp: C: EHLO [192.168.1.13]
mailnews.smtp: S: 501 EHLO JDBFvggTYD6Em internal error AUP#EML-005

It would send and receive this:

mailnews.smtp: C: EHLO my.host.name
mailnews.smtp: S: 250-smtp.<MY.ISP> hello [xxx.xxx.xxx.xxx], pleased to meet you

I could have also changed my LAN IP address and it would have worked… you can basically send almost(?) anything you want.

The reason is that when you send your EHLO command, and everything is correct, the server recognise you by your WAN IP address and the handshake continues.

The preference you ask? Oh yes here it is:

You can set it in the advanced preference settings in Betterbird/Thunderbird or in a prefs.js file.

You have also 2 choices.
If you have only 1 SMTP server configured (default)

pref: mail.smtpserver.default.hello_argument
string: your.host.name

Or if you have more than 1 server configured

pref:mail.smtpserver.smtpNN.hello_argument
string: your.host.name

NN is the number you get when you look for the SMTP server in 
Help -> Troublesooting Information
If you have more than 1, it could be a good idea(?) to also adapt your host name.

By doing this, I was able to send email as I use to.

Now, I will have to wait a few days before I get off of their banned list (I hope) and recontact my service provider just to make sure everything is back to normal. I will probably then remove the mail.smtpserver preference, as I have been told that a fix should land in the trunk enventually. Meaning that instead of sending the address literal it would send the computer’s name (FQDN) by default.

Just in case you’re interested:
Using 127.0.0.1 (nonrouteable IP) as HELO string

And also (the patch):
Attachment #249368: patch v3 -u for bug #244030

NOTE: Look at the dates…

So, that’s it, that is the end of the saga :smile:

Thanks to anyone who tried to help.

1 Like