dmeszler said

Not so much a question, but an observation for other users. Having been running Thunderbird for years. Great program. Updated to 38.1.0 this morning after prompting and my ability to send e-mail was immediately compromised (ability to receive was not affected). Tried a few tweaks (plus turned off firewall, etc.) to no avail and had to reinstall 31.7 to get functionality back. I'll need to turn auto update off as the program is now trying to update itself again, but thought I'd throw this out there in case anyone else ran into an issue.

Quick update. The autoupdate actually just installed 38.0.1 (not 38.1.0) and that is working fine, so looks like the issue is between 38.0.1 and 38.1.0. If I get some spare time later, I'll give 38.1.0 another go.

Additional Update. Went ahead and gave 38.1.0 another shot. Same issue. As long as I had it back up, I may as well quote the error message:

Sending of the message failed. The message could not be sent using Outgoing server (SMTP) XXXXXX.com for an unknown reason. Please verify that your Outgoing server (SMTP) settings are correct and try again.

XXXXXX is masked server name (private server)

Same message actually appears when I also try sending without authentication (via the same port 465). Reinstalled 38.0.1 and back in business without a hitch. Definitely something different in 38.1.0.

When you have time, can you check something.

Currently using 38.0.1

• Tools > Options > Security > Passwords tab
• click on 'Saved Passwords'
• Click on 'show Passwords'

I presume both the mailbox and smtp account passwords are visible.

Then upgrade to 38.1.0 and perform the same as above. Is there both mailbox and smtp showing passwords as before? What do you see?

All account usernames and passwords are listed and identical in both 38.0.1 and 38.1.0. I saved and compared (visually) screenshots of each. Could see no difference. FYI, there are two comcast mailbox accounts and seven "private domain" mailbox accounts (only one of these is used regularly by me, the others are accounts for other users that I keep to debug any intermittent problems they may encounter). Also correctly listed are two smtp accounts, one for comcast and one for the "private domain" (the "private domain" account is the default and is used regularly for outgoing mail).

I actually have 5 outgoing smtp protocols defined, one comcast and four for the "private domain." The default "private domain" protocol is the only one used, the others were for debugging purposes -- mainly used when I was setting up the authorized smtp protocol several years back. At any rate, I tried sending using all five after the 38.1.0 reinstall and here's what happened:

private domain ssl/tls port 465 authorized sender with pswd -- error as above

private domain ssl/tls port 465 mailbox user without authentication -- error as above

private domain no security port 25 without password -- time out

private domain no security port 25 with authorized sender and password -- time out

comcast ssl/tls port 465 comcast user and password -- mail went right through without problems

I assume the port 25 timeout is due to that port being closed, but have no idea what is causing the port 465 inconsistencies between the versions. I would use the comcast outgoing accounts but this can cause transfer "error" issues for some mail screeners (at least the last time I was using that method -- that is actually the reason I set up the "private domain" authorized sender protocol).

Happy to provide any other info if you have ideas. Thanks for taking the time.

Is this an Exchange server with NTLM authentication?

I'm not familiar with what an Exchange Server is (I think it's an MS protocol, but I may be totally wrong), but I do not think that is what I have. I have a privately registered domain name running on an eApps VPS with a dedicated IP and associated IMAP/POP mail server. Not sure if this is the right terminology, but hopefully that provides an at least understandable description.

For what it is worth, I do recall older Thunderbird updates requesting certificate exceptions, but that has not happened in some time and does not seem to play a role in the difference between 38.0.1 and 38.1.0 as both were updates to what I was running before yesterday.

The specific outgoing mail settings are:

Server Name = XXXXXXX.com Port = 465 Connection security = SSL/TLS Authentication method = normal password User Name = YYYYYYYY

The user name does not explicitly include the @XXXXXXX.com extension as that was required to get it to work originally. I have, however, also tried sending with the @ extension included and got the same error.

Also, I have a second test outgoing protocol that is:

Server Name = XXXXXXX.com Port = 465 Connection security = SSL/TLS Authentication method = no authentication User Name = not applicable (blanked out)

This gives the same error.

Look in Tools menu > error console for errors referring to Diffie-Hellman. If they exist contact your mail provider about when they will be fixing CVE-2015-4000 so you can get your mail.

I am having the same problem and I checked the error console and have this message

Timestamp: 7/16/15 2:34:41 PM Error: An error occurred during a connection to mail.saundersbook.ca:587.

SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message.

(Error code: ssl_error_weak_server_ephemeral_dh_key)

We use Sendmail. Our own mail server. What do we need to do to correct this? Thanks

I think you are on the right track Matt. Thanks. I reinstalled 38.1.0 again and tried sending (there is no problem receiving mail), and I do see an error message identical to that listed by hodgsonc above (with a different server name of course). There are also a bunch of RFC 5746 errors, but these come through on both 38.0.1 and 38.1.0 and do not seem to have any actual effect (i.e., they behave more like a warning than an error). The DH error is, however, apparently fatal.

I will switch back to 38.0.1 again and try to research this further. Unfortunately, I am a one man operation and wear many hats (only one of which I am probably qualified to actually wear), so it may take me some time to understand and resolve this issue assuming I have to go in and mess with my server. I will post any additional info as it becomes available. Thank you for pointing me in the right direction.

What do we need to do to correct this?

See https://weakdh.org/

Thanks christ1. I have sent a message to my hosting company (eApps) to see if they have a suggested fix. If that is unsuccessful, I will wade through the code in the source material provided in your link.

chris1. I made this change to our sendmail server.

Sendmail

These changes can be made in the LOCAL_CONFIG section of your /etc/mail/sendmail.mc

Cipher Suites

O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA DH Parameters

O DHParameters={path to dhparams.pem} Reload configuration

sudo service sendmail restart

I then updated my Thunderbird to 38.1 and it still did not work with the same resulting error. Am I missing a step?

I understand that concept of me myself and I will do it. You are one of those I would epect to stay on 31 for a month or two while your work out what needs to be done and do it.

Looking at the sendmail website I see Sendmail 8.15.2 is available. the realease notes for which state is changes things for logjam, which is basically another name for this. So perhaps the easiest option would be just update sendmail.

Thanks Matt and christ1. Received a response from my host that basically indicated that I needed to generate a new private key and certificate. So I think we are all on the same page, I just need to refresh my memory as to how I did this a few years back. I'm sure the logjam info will help and I'll blunder my way through it. I am tied up with "real" (i.e. paying) work for a few days, but I'll post again when I've had a chance to bring my server setup into compliance. Can't thank you guys enough for educating me on this and saving me who knows how much time tracking this down. If I run into anything that might be of use to others, I will certainly include that in my follow-up post. Take care ...

Christ1 tells me off line that he believes thatthis add-on, installed in Thunderbird may offer a working connection until your get to the rest. At this point is it all surmise on our part largely based on the Bug report. But if you would not mind being the guinea pig. Please install it and let us know how it goes.

You can just call me Mr. Pig. Worked like a charm. Updated again to 38.1.0 and then tried sending before and after installing the add on. Before installation same ole problem. After installation, mail went right on through. Error log now contains about a million (okay, slight exaggeration) messages telling me my site uses an SHA-1 certificate and that I should get off my %$# and upgrade. I will do this and confirm that I can then disable the add-on, but it definitely does what it says it does. Thanks to everyone for their time and expertise ... invaluable and much appreciated. Man it's been a tortuous journey from Assembler and FORTRAN to trying to keep tabs on what is going on now. Many, many thanks for making it easier. Have a great weekend, wherever you might be.

Sitting in the "not as cold as it was" Flinders Ranges Mr Pig.

Thanks to you we now have confirmation of a work around which is very handy. As you demonstrate, not everyone can fix everythings on day one so workarounds are always very handy..

Good luck.

Still no joy for me. I am getting an RFC 2822 error trying to send (I get e-mails just fine) or forward to GMail, Hotmail--even through TB to myself..

Geez Matt, I feel so geographically pedestrian now (east coast US). Stay warm. I was going to mark this solved, but I see there is another issue, so I will let it ride until advised otherwise as I am not sure of the protocol and I don't want to accidentally step on someone else's toes.