I configured exim mail server on centos. It is working with no encryption type. But not with SSL and TLS. I din't get correct solution for this type of error. Can anyone tell solution and why this error message in exim main.log file?
The error message is like below in the exim main.log file.
2015-03-17 10:34:16 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=acp-node [10.7.2.137] input="\026\003\001"
(input sent without waiting for greeting) ... input="\026\003\001"
In short: You are trying to use implicit TLS on a port where explicit TLS is needed.
In detail: There are two ways to use TLS with SMTP:
implicit TLS, that is TLS from start. This is used on port 465 (smtps). This mode is in some SMTP stacks simply called "SSL".
explicit TLS, that is start with plain SMTP and upgrade to TLS with the STARTTLS command. This is used on ports 25 (smtp) and 587 (submission). This mode is in some SMTP stacks simply called "TLS".
If you look around at the questions regarding use of SMTP with TLS you will find lots of confusion about how to use these modes with the various setups. And you will find lots of bad code which tries to use implicit TLS where explicit TLS is needed.
What you see is the result of the client trying to use implicit TLS on a port not suitable for this. \026\003\001 (or hex 16 03 01) is the start of a TLS 1.0 handshake and input sent without waiting for greeting refers to the fact, that the client is sending data first without waiting for the server to send the (plain text) SMTP greeting.
Judging from the error log entry, your mail client 10.7.2.137 is trying to establish a secure (TLS) connection but your Exim server is not expecting it.
Most probably, TLS is not configured properly in your Exim configuration file. You can refer to http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html for tutorial.
The solution is, therefore, to edit your Exim configuration file, making sure TLS certificates are defined and tls_advertise_hosts is set; and then restart Exim.
Related
I am puzzled a bit about Postgres option sslmode=prefer. It implies that it negotiates with the server to figure out whether the server supports TLS or not.
I am curious how it's done. Does it try TLS first and if it fails, try without TLS or am I missing something in TLS (or Postgres) which allow them to truly negotiate this?
Does it try TLS first and if it fails, try without TLS
Yes. And when both attempts fail, this might be visible, as two different error messages might be produced.
Some additional info on top of #janes answer:
https://www.postgresql.org/docs/current/protocol-flow.html
To initiate an SSL-encrypted connection, the frontend initially sends
an SSLRequest message rather than a StartupMessage. The server then
responds with a single byte containing S or N, indicating that it is
willing or unwilling to perform SSL, respectively. The frontend might
close the connection at this point if it is dissatisfied with the
response. To continue after S, perform an SSL startup handshake (not
described here, part of the SSL specification) with the server. If
this is successful, continue with sending the usual StartupMessage. In
this case the StartupMessage and all subsequent data will be
SSL-encrypted. To continue after N, send the usual StartupMessage and
proceed without encryption.
For years I used port 465 for my outgoing email with no problem, but suddenly my desktop client (eM Client) refused to send messages. I went to my provider for advice and they claim they haven't changed any settings and it's my client's fault. Hmm... I've changed the port to 587 and it works smoothly now.
But I've noticed that my mobile client (AirMail on iOS) still uses port 465! What's more, when I tried updating it to 587, it stopped working and I had to revert to 465.
So now I have working mail on desktop on port 587 and on mobile on port 465, all with the same provider! It's no real issue, but I can help wondering: what's the real reason for it? Can it be actually attributed to the client software I use?
It would be much easier to provide useful answers if you could provide more details, such as what error responses your clients got from the server when they tried to send email, and what you tried to do to fix the problem.
This is a bit of a wild guess: maybe your desktop is no longer able to send email over a secure (TLS) connection on port 465, but it can send email over an insecure connection on port 587. That might indicate a problem with a certificate.
Indeed! Here's the error message I was getting:
[CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk QUOTA STARTTLS AUTH=PLAIN AUTH = LOGIN] Dovecot ready.'.
I may be wrong as I have no access to my desktop at the moment but I believe that sending over 587 happens with SSL, at least that's the security set in the account configuration.
I have a problem for a couple of days ago me going crazy, I have a script that sends mails using phpMailer and arsys.
The fact is that the overnight stops working, check the code and seems fine, it's more, it works correctly if I run it from the test server that comes through another IP.
I found that the server was not on any spam blackList and found the reference to be to a PBL, me worry about removing it from there.
Anyway, I still can not send mail from that server and both my other test script I programmed work correctly on development server but not on the production server.
The error that is specifically this
SMTP -> ERROR: EHLO not accepted from server:
SMTP -> ERROR: HELO not accepted from server: 220 ESMTP Postfix smtp-04.servidoresdns.net
SMTP -> ERROR: AUTH not accepted from server: 250-250-llsg993-a04.servidoresdns.net PIPELINING 250-SIZE 51200000 250-ETRN 250-250-STARTTLS AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN 250-AUTH = DIGEST MD5 CRAM-MD5 LOGIN PLAIN 250-250 8BITMIME ENHANCEDSTATUSCODES
It says it can not authenticate the credentials are fine but since the same script from another server goes perfectly.
Also came through a tcptraceroute to port 25 SMTP server.
Only strange thing I see is that when running
tcptraceroute p 25 smtp.miservidor.com
He says:
Sorry, Local Requested port is already in use. Use P, instead of p, to override.
But after using P instead of p and functions
Anyone shed me some light on this?
Who may be filtering my IP address ??
It's very common for ISPs to block outbound connections to port 25 by default. Try using SMTPSecure = 'tls' and Port = 587 - that server definitely responds on that port.
Connection problems are covered in the PHPMailer docs.
I noticed that never answered this question, the problem was the time, the function did not have enough time to contact with server. I increased the time in phpMailer class and everything went back to work.
SMTP allows unecrypted communication over port 25. For some servers (like Google's MX servers) I'm able to switch to a TLS connection using STARTTLS after making the initial unencrypted connection.
S:220 mx.google.com ESMTP l1si352658een.133
C:EHLO mail.example.com
S:250-mx.google.com at your service
S:250-SIZE 35882577
S:250-8BITMIME
S:250-STARTTLS
S:250-ENHANCEDSTATUSCODES
S:250 PIPELINING
C:STARTTLS
S:220 2.0.0 Ready to start TLS
[socket switches to TLS here]
C:EHLO mail.example.com
...
However, I would also like to support straight SSL connections and I'm wondering whether most mail servers prefer starting with SSL or starting with TCP and then moving to TLS after a connection is made.
Unless you have prior arrangements with the administrator of a sever, don't try to connect using SSL. Port (465) was used for SSMTP or SMTPS (SMTP over SSL). Connections to this port were expected to start the connecton with SSL. Use of this port and protocol has been abandoned now that StartTLS is available.
There are two ports which may support SMTP with StartTLS. Neither are expected to support SSL without StartTLS, and will likely drop the connection if you try. Both the SMTP (25) and Submission (587) may support StartTLS. If it is supported, it wlll be listed in the response to an EHLO message. You can then initiate the StartTLS process. See RFC 3207 for more details.
It appears from your comments, that your real concern is how to verify the certificate. That is a different but related question. It also assumes that mail servers are not using self-signed certificates. In my case, I use a self-signed certificate. This works well for me as StartTLS is rarely, if ever, used for SMTP (port 25) connections. I have reasonable control over the clients connecting for message Submission (port 587 or port 25) that must authenticate before sending messages. In my experience, StartTLS is mainly used to secure the connection for clients that must authenticate before sending email.
The support for SSL/TLS on connect (SMTPS) or SSL/TLS after STARTTLS really varies from one server to another, depending on the software and how they've been configured.
The main advantage of SSL/TLS on connect is that it doesn't require any changes in the application protocol. In fact, you could wrap the connection using something like stunnel on each side.
The main advantage of SSL/TLS after STARTTLS is that it can be done on the same port. Another advantage could be to be able to host multiple host names (replacing the need for Server Name Indication at the TLS level), but I'm not sure this has ever been used for SMTP servers.
STMPS (SSL/TLS on connect) doesn't have an official specification and uses a port number for which it is not registered (465). It's also deprecated, in theory. Yet, a number of servers can support it (e.g. Exim) and will be able to support both if they are able to do so: it will be up to the hosting service to choose what to configure.
If you're writing a client and already have support for STARTTLS, it should be fairly cheap to support SSL/TLS upon connect too. It's certainly a good idea to support both, since it will be usable by a wider number of users (if I remember correctly, Gmail used to support only SMTPS at some point, and it can also be useful in case of a firewall that would block one of the ports only).
Both can offer similar levels of security, as long as SSL/TLS is used, one way or another (and that proper certificate verification, including host name, is performed).
There is generally some confusion regarding the difference between SSL and TLS. For some reason, it seems that a number of e-mail software implementations failed to realise that the most important word in "STARTTLS" is "START", not TLS (in terms of connection mode and protocol choice). This confusion has unfortunately propagated to some software configuration options (even in popular mail clients) and thus in ISP documentations. Expect your users to be confused.
Whichever mode you want to support, make sure it doesn't have a "Use TLS, if available" option, which would fall back to a plain exchange if SSL/TLS wasn't available: this opens the connections to MITM attacks.
I could successfully send e-mail notification in Hudson using gmail as the smtp server.
But when I try to configure our own smtp server, it gives the following error when trying to send the test mail:
Failed to send out e-mail
javax.mail.MessagingException: Exception reading response;
nested exception is:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
Are there any special configurations with the e-mail notifications???
Edit:
Also does it require enforcing the security certificate and if so is there a way to achieve it???
Thanks
Please try using the following settings:
SMTP SERVER : smtp.gmail.com
use SMTP Authentication : true
use SSL : true
SMTP port : 465
I had this problem too. My solution was to make all the necessary configuration (check ssl box and stuff) and CLICK THE SAVE BUTTON before use the test mail.
i just had this issue before clicking the save button.
Changing the SMTP port from 587 to 465 also resolved this issue for me, even though I'm using an alternative SMTP service:
SMTP server: smtp.mandrill.com
Use SMTP Authentication: true
Use SSL: true
SMTP Port: 465
From what I can tell (disclaimer: I am by no means a Hudson/Jenkins expert)
the Hudson/Jenkins email plugin supports SSL encrypted SMTP communication - however this implementation requires that communications are encrypted from the get go.
When connecting on port 587, the server on the other end may expect a STARTTLS command (see this SSL vs TLS vs STARTTLS article). This command is sent using plain-text to 'upgrade' the connection to use SSL/TLS.
Hudson/Jenkins instead attempts to start negotiating SSL on port 587, which is promptly rejected, resulting in the following error:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
I also tried adding additional JAVA options "-Dmail.smtp.starttls.enable=true" (configured in /etc/default/jenkins on Unbuntu) to enable TLS:
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Dmail.smtp.starttls.enable=true"
Unfortunately this didn't resolve the issue for me.
After changing the port to 465, the SSL negotiation occurred correctly and the communication succeeded.
Hope that helps.