Created attachment 78671 [details]
This shows ALL the communication taking place over a network, using Wireshark, once the "Test Settings" button is clicked.
Problem description: When setting up an E-mail mail merge account that uses an SSL secure connection on port 465, for LibreOffice Writer version Version 184.108.40.206 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3), the test to see if it succeeds fails. It also fails if one ignores the test results and actually tries to do an E-mail merge, no real surprise, just an FYI.
Steps to reproduce:
1. Open Tools > Options > LibreOffice Writer > Mail Merge E-mail
2. Enter information appropriate to connect to a POP3 mail server using SSL, port 465, and which requires Server Authentication.
3. Press Test Settings to verify that the server was set up correctly.
The test shows that it is successful in establishing a network connection. However, the test shows (after a LONG time) that it failed to find the outgoing mail server.
I expect the test to succeed when using an SSL connection to a mail server.
LibreOffice produces the following error message -
LibreOffice could not connect to the outgoing mail server. Check your system's settings and the settings in LibreOffice. Check the server name, the port and the secure connections settings
<class 'smtplib.SMTPServerDisconnected'>: Connection unexpectedly closed, traceback follows
C:\Program Files\LibreOffice 4.0\program\python-core-3.3.0\lib\smtplib.py:372 in function getreply() [raise SMTPServerDisconnected("Connection unexpectedly closed")]
C:\Program Files\LibreOffice 4.0\program\python-core-3.3.0\lib\smtplib.py:319 in function connect() [(code, msg) = self.getreply()]
C:\Program Files\LibreOffice 4.0\program\python-core-3.3.0\lib\smtplib.py:238 in function __init__() [(code, msg) = self.connect(host, port)]
C:\Program Files\LibreOffice 4.0\program\mailmerge.py:99 in function connect() [self.server = smtplib.SMTP(server, port,timeout=tout)]
Internet (Google) searches reveals that this has been an ongoing problem for quite a few years, in particular when users are using a GMAIL account that requires an SSL connection on port 465. However, I am running the Apache James email server, on my own internal SOHO network and am experiencing this problem with LibreOffice Writer as well, so this CANNOT be blamed on an improper server configuration. (FYI My Thunderbird e-mail clients all can connect successfully to my James email server, using SSL and port 465 without any problem.)
Furthermore, log files from the Apache James server, and more definitively, a trace of network traffic using Wireshark, reveals that there is a single packet sent from the system, from which the LibreOffice E-Mail merge setup is done, to the system on which my James e-mail server is running. This is followed by an ACK packet from the e-mail server back to the system running the E-Mail merge setup, which surprisingly replies to this ACK with another ACK packet. This is ALL the communication that occurs, and there is no attempt to follow up with an attempt to actually send a 'Helo' message or log into the email server to test if LibreOffice Writer can actually find/communicate/authenticate itself with the e-mail server.
I therefore surmise that this initial communication between the two systems is done for the purpose of establishing that there is a network connection, but not for the purpose of checking if the e-mail server can actually be used/authenticated with. That sort of communication is completely non-existent, which places the fault within LibreOffice Writer.
I will attach a document showing the output trace from Wireshark, in the event that it may prove helpful.
Operating System: Windows 7
Version: 220.127.116.11 release
Nevermind my surprise about the ack packet going back to the server from the client, I did some further research and that is the expected behavior between a client and a mail server when initial establishment of a network connection is being made.
Then next step however, is that LibreOffice should initiate a Hello message to be sent to the email server, to start the process of certificate verification and key exchanges, when SSL/TLS communication is being initiated. That step is NOT taking place, and since it is the responsibility of LibreOffice, as the client of a mail server, to initiate this, again this shows that the failure in establishing and verification of SSL communication with the e-mail server lies with LibreOffice and NOT with the mail server.
Same probleme here. Reproduced on Windows, and Ubuntu. With LO 3.5, but also 4.0.3.
Scenario to reproduce is simple :
In Windows :
Tools->Options->LibreOffice Writer->Mail Merge E-mail
Fill in the details (I use Gmail's smtp.gmail.com, with SSL enabled and port 465).
Select Server Authentication, check "Server requires authentication".
Enter Username (@gmail.com address) and password.
Close the settings by clicking OK.
Open Tools->Options->LibreOffice Writer->Mail Merge E-mail
Check settings are properly memorized.
Click "Test settings".
Window pops up with "Test Account Settings"... and that hangs.
Note... If you change the port from 465 to 587 it works fine...
(In reply to comment #3)
> Note... If you change the port from 465 to 587 it works fine...
NO. While this may work with gmail, which I believe supports both SSL on port 465 and TLS on port 587, I strongly disagree with this answer as a general workaround. LibreOffice/Writer should be able to establish an SSL (and TLS, if LibreOffice/Writer also wants to claim that TLS is supported,) connection on ANY port. AFAIK port numbers and their assignment/usage is only done as a convention, there is no mandatory standard. The mail server can establish an SSL or TLS connection on any port of it's choosing, and I know some servers choose unusual ports in order to avoid robo attacks. Client applications must then conform to whatever port their server wants to use. Port 465 is the usual port on which SSL connections are made, and port 587 is the usual port on which TLS connections are made. LibreOffice/Writer purports to support SSL connections (which is a subset of the TLS protocol) and their setup dialog ONLY mentions SSL, not TLS. Therefore Port 465, as well as any other port number, should be supported.
Changing the port number to 587 is NOT an acceptable workaround, as most users have no control over what port their email server wants to use to establish an SSL or TLS connection.
It actually took me ages to finally get a working connection from LO to my Gmail account because the default SSL connection proposed in the LO fails to establish a connection and then eventually times out. On Mac, this causes the spinning beach ball syndrome, and requires a force kill of the app to regain control.
In the end, I had to reassign ports, which is not what a normal user should have to do.
Adding Caolan on CC, as the mailmerge stuff is, or was, his area.
For gmail, these are the settings that worked for me :
SSL option ticked
(In reply to comment #6)
> For gmail, these are the settings that worked for me :
> SSL option ticked
> Port 25
Under "Server Authentication"
Tick "Outgoing mail server (SMTP) requires authentication"
Select "The outgoing mail server requires separate authentication"
User name : enter full Gmail address here, including the @gmail.com
Password : fill in with password
No need to configure the Incoming Mail Server options
Bear in mind that I don't actually know where the problem lies within the code, so can't take this much further.
So from the above comments, SSL connections appear to work on ports 25 and 587, but not on port 465, is that it ? In which case, I guess we should correct the title of the report.
I have the exact same bug, same behavior and everything, on 64-bit Ubuntu 13.04, with Libre Office 18.104.22.168.
Since my university's SMTP server requires SSL and port 465, until this is fixed I cannot use Libre Office to send mail merged documents. Instead, I use an old version of OpenOffice that doesn't have the bug (version 3.3.0).
(In reply to comment #9)
> So from the above comments, SSL connections appear to work on ports 25 and
> 587, but not on port 465, is that it ? In which case, I guess we should
> correct the title of the report.
Alex - I am not sure that changing the title of this report is a good idea. AFAIK mail servers are only required to honor a particular protocol IF AND ONLY IF the client application connects to that mail server on the port to which it is configure to use that protocol on. I know this is the way my Apache James email server works. I suspect that LibreOffice is quite capable of supporting both TLS and open connections but is not properly handling SSL connections. I strongly suspect that when people are connecting to a mail server on port 25 they are giving up the encryption feature of SSL and communicating with their mail server in open/plain text. That is NOT what the expected behavior for SSL communication is and while it may appear to be working by using another port, IT IS NOT! Using port 587 probably switches the client over to using TLS, not a bad alternative if you want encryption, BUT it will only work if the mail server supports TLS.
I choose SSL because it is slightly more secure than TLS because the HELO message is not sent in plain text as it is via TLS. TLS is more flexible than SSL in some respects, but remember these are two very different protocols, and if LibreOffice is going to claim that it supports both, which it should, then it is imperative that SSL connections be supported and work properly.
Do not think that just because people can get a mail merge connection working, by using alternate ports, that this is an adequate workaround, IT IS NOT! I as a user have good reason to want and expect an encrypted channel, between LibreOffice and my mail server to work properly.
LibreOffice sends these mails via python see mailmerge.py for details. Its not a difficult script to understand. Someone who has the problem should have a look through that and debug what's going wrong. Perhaps a misuse of python, perhaps a bug in the shipped version of python, or perhaps a buggy workaround for an older version of python which causes trouble now.
updating version and platform as per comment 2.
I couldn't figure out the way to have mailmerge working with my Gmail SMTP but when I did the debug of the mailmerge.py script I've discovered that a SSL connection isn't handled properly.
At the line where the server object is created I found:
self.server = smtplib.SMTP(server, port,timeout=tout)
but in case of SSL connection the correct statement should be:
self.server = smtplib.SMTP_SSL(server, port,timeout=tout)
So, I did this simple change and my Gmail SMTP (smtp.gmail.com) works perfectly on port 465.
I didn't even checked the "Use SSL" checkbox in the mailmerge configuration windows.
I think a good patch should make a choice between smtplib.SMTP and smtplib.SMTP_SSL according to the "Use SSL" checkbox.
I've encountered this annoying problem in both 4.2 and 4.3 release on both Linux and Windows. Thx to Andrea Tessadri regarding the self.server setting. But this isn't sufficient if the SMTP server doesn't expect STARTTLS but expects SMTPS (port 465). In this case, the instruction "self.server.starttls()" will fail. For SMTPS, one has to replace the line "self.server.starttls()" by "self.server.use_ssl = True;".
I got the very same behaviour under LO 22.214.171.124 Linux : my server requires SSL and port 465.
Additionally, I believe that the referred bugs are all duplicates.
... and this is very annoying, since I have NO workaround for the needed mailmerge !
*** This bug has been marked as a duplicate of bug 63388 ***