msmtp

As a preface, is there a way to configure msmtp to bounce emails that
have failed transmission?  Right now I have to resort to checking the
logfile if it seems an outgoing mail has vanished.  I use msmtp with
Mutt (version 1.5.16)

So, on to the main question, what is the meaning of this error message I
suddenly began to receive one day?

Oct 26 12:10:23 host=3Dsmtp.umr.edu tls=3Don auth=3Don user=3Dxxx
=66rom=3Dxxx@... recipients=3Dxxy@... errormsg=3D'TLS handshake
failed: The Diffie Hellman prime sent by the server is not acceptable
(not long enough).' exitcode=3DEX_PROTOCOL

msmtp version 1.4.13

account umr
host smtp.umr.edu
=66rom xxx@...
auth on
user xxx
password xxx
tls on
tls_certcheck off
logfile /home/xxx/Mail/msmtp.log


--=20
Ryan C. Underwood, <nemesis@...>

Re: [msmtp-users] Diffie Hellman prime sent by the server is not acceptable From: Martin Lambers <marlam@ma...> - 2007-11-08 18:10 On Thu, 08. Nov 2007, 11:44:42 -0600, Ryan C. Underwood wrote: > As a preface, is there a way to configure msmtp to bounce emails that > have failed transmission? Right now I have to resort to checking the > logfile if it seems an outgoing mail has vanished. I use msmtp with > Mutt (version 1.5.16) No, msmtp implements the sendmail commandline interface. It can only signal failure by returning an error code. In the default configuration, Mutt does not put msmtp in the background, so you get an immediate failure notice. > So, on to the main question, what is the meaning of this error message I > suddenly began to receive one day? > > Oct 26 12:10:23 host=smtp.umr.edu tls=on auth=on user=xxx > from=xxx@... recipients=xxy@... errormsg='TLS handshake > failed: The Diffie Hellman prime sent by the server is not acceptable > (not long enough).' exitcode=EX_PROTOCOL You upgraded your GnuTLS library recently, right? Newer GnuTLS version check more strictly for secure TLS session parameters than older versions, or OpenSSL. See also this Debian bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344 In short, you have these options: - Downgrade to an older GnuTLS version (not recommended) - Use OpenSSL instead of GnuTLS (not recommended) - Ask the SMTP server admins to use more secure settings (recommended if the admins will listen to you) - Apply the one-line patch mentioned in the Debian bugreport to msmtp. This will relax the default GnuTLS security settings (recommended if fixing the server is not an option) Future msmtp version will most likely *not* override the GnuTLS default settings. The GnuTLS people probably have very good reasons for the stricter checks. In addition, if one day some session parameters are considered insecure that are considered ok today, then a simple GnuTLS update will fix all applications that don't mess with the settings themselves. Martin

Re: [msmtp-users] Diffie Hellman prime sent by the server is not acceptable From: Ryan C. Underwood <nemesis-lists@ic...> - 2007-11-08 23:51 Attachments: Message as HTML      On Thu, Nov 08, 2007 at 07:10:28PM +0100, Martin Lambers wrote: >=20 > No, msmtp implements the sendmail commandline interface. It can only > signal failure by returning an error code. In the default configuration, > Mutt does not put msmtp in the background, so you get an immediate > failure notice. I see, I'll have to wrap it with a script that checks the exit code then. I was forced to configure it to run in the background because of transmission of large attachments... :-( > You upgraded your GnuTLS library recently, right? Yes. Such a quick response makes me apologize for not googling correctly. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D440344 >=20 > In short, you have these options: > - Downgrade to an older GnuTLS version (not recommended) > - Use OpenSSL instead of GnuTLS (not recommended) > - Ask the SMTP server admins to use more secure settings > (recommended if the admins will listen to you) They don't. They insist that because the following command works on their end: $ openssl s_client -connect smtp.umr.edu:25 -starttls smtp that the mail server is not insecure and the problem is my client. > - Apply the one-line patch mentioned in the Debian bugreport to msmtp. > This will relax the default GnuTLS security settings=20 > (recommended if fixing the server is not an option) I will do this. > Future msmtp version will most likely *not* override the GnuTLS default > settings. The GnuTLS people probably have very good reasons for the > stricter checks. Does this mean that a patch to msmtp is always required if the server is broken in this manner? --=20 Ryan C. Underwood, <nemesis@...>

Re: [msmtp-users] Diffie Hellman prime sent by the server is not acceptable From: Martin Lambers <marlam@ma...> - 2007-11-09 05:57 On Thu, 08. Nov 2007, 17:51:26 -0600, Ryan C. Underwood wrote: > > No, msmtp implements the sendmail commandline interface. It can only > > signal failure by returning an error code. In the default configuration, > > Mutt does not put msmtp in the background, so you get an immediate > > failure notice. > > I see, I'll have to wrap it with a script that checks the exit code > then. I was forced to configure it to run in the background because of > transmission of large attachments... :-( Maybe the msmtpqueue scripts can be a starting point for this. See the scripts subdirectory of the msmtp source. > > - Ask the SMTP server admins to use more secure settings > > (recommended if the admins will listen to you) > > They don't. They insist that because the following command works on > their end: > > $ openssl s_client -connect smtp.umr.edu:25 -starttls smtp > > that the mail server is not insecure and the problem is my client. They have a point. It is unfortunate that GnuTLS and OpenSSL have different requirements here. I do not know enough about cryptography to decide which one is right, but if in doubt, I go with the stricter checks. > > Future msmtp version will most likely *not* override the GnuTLS default > > settings. The GnuTLS people probably have very good reasons for the > > stricter checks. > > Does this mean that a patch to msmtp is always required if the server is > broken in this manner? If you put it that way, it does not sound like a good idea ;) I don't want to add a set of configuration commands that can change every TLS session parameter requirement. But perhaps one could add a single command 'tls_lax_security' which enables the weaker requirements of older GnuTLS versions and/or OpenSSL. Or a command 'tls_security' with the settings "off" (no requirements whatsoever), "lax" (the old set of requirements), "default" (library default). What do you think? Martin

7 messages have been excluded from this view by a project administrator.