newest version of msmtp not working

brianb · 2012-03-31 13:49:58

I'm not sure if this is the right subforum, but here goes...

I just found out yesterday that none of the emails I've written in the past week from my school account were ever received! (Most of them weren't really important, until one that I sent yesterday, hence why it took so long to discover.)

I use Mutt with msmtp, so after troubleshooting, double checking .msmtprc and .muttrc, etc., I decided to check my pacman logs and noticed that I upgraded msmtp a week ago (msmtp-1.4.27-1 > msmtp-1.4.27-2). I just now downgraded and all is well again.

For completeness, here is my .msmtprc:

account gmail
host smtp.gmail.com
port 587
protocol smtp
auth on
from brian.blah@gmail.com
user brian.blah@gmail.com
password <my password>
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile "~/.mutt/log"

account mcgill
host smtp.mcgill.ca
port 587
protocol smtp
auth on
from brian.blah@mail.mcgill.ca
user brian.blah@mail.mcgill.ca
password <my password>
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile "~/.mutt/log"

As you can see, I've got a school account plus a gmail one. My gmail one worked totally fine with the new version of msmtmp, but not my school one.

Also, you can see that I decided to add a log file so I could see the errors (before downgrading). This was the error it would give me when using my school account:

errormsg='GNU SASL: GSSAPI error in client while negotiating security context in gss_init_sec_context() in SASL library.  This is most likely due insufficient credentials or malicious interactions.' exitcode=EX_SOFTWARE

Here are my questions:

(1) Based on the above info, is this a problem on my side (that I can fix), or a problem with the new package? In either case, what should I do?

(2) For the future, is there a way to be notified, preferably in Mutt, when an email is not successfully sent/received? Right now, Mutt says "Mail sent!" even when msmtp gives errors. I'd prefer not to have to check my log after sending each email.

Thanks to anyone who has some advice!

Brian

rsabo · 2012-04-06 15:28:49

Hey Brian,

I had the same problem on my school account. I'm not sure exactly what the problem is, but it somehow relates to msmtp's gssapi authentication support. Looking at the changelog from 1.4.27-1 to -2, it looks like the only substantive thing they changed was adding gsasl as a dependency. Changing "auth on" to "auth plain" in .msmtprc fixed the problem for me. It should still be secure, since you're connecting over tls first. I'll file a bug report when I figure out exactly what the problem is.

--ryan

edit: oh, and as for the mutt question, I get errors. Don't know why, my msmtp setup is otherwise exactly the same, and there's nothing special in my muttrc

Last edited by rsabo (2012-04-06 15:37:44)

brianb · 2012-04-06 18:17:23

Hi Ryan,

Thanks for the response. Nice to know I'm not the only one having the issue. Thanks also for filing the bug report (whenever you get a chance).

For the Mutt error stuff, I just took a look at my muttrc and figured it out. I've got the following option set

set sendmail_wait = -1

which sets the number of seconds to wait before putting the $sendmail process in the background. So -1 means put $sendmail in the background immediately*, which in turn means that if an error occurs, you simply won't know. Setting it back to 0 (default) fixes it.

*I originally set it to -1 because my school account sometimes takes up to 10 seconds to go through, and I don't feel like waiting that long. Guess I'll change it to 1 or 2, that way any error will still be processed (since I imagine errors occur within 1-2s), and normal mail will be sent in the background after 1-2s.

Last edited by brianb (2012-04-06 18:19:32)

Stebalien · 2012-04-06 20:01:39

Also, if you don't want to loose failed emails, try using the msmtp-queue scripts (in the msmtp package).

brianb · 2012-06-06 12:54:41

Hi again,

Using

auth on

still gives me the same error, and changing to

auth plain

(as per Ryan's advice) does not work either:

errormsg='the server does not support authentication method PLAIN' exitcode=EX_UNAVAILABLE

However, setting

auth login

does work, so all is good now.

(Until now, I simply refused to upgrade msmtp... but that's not smart!)

Arch Linux

#1 2012-03-31 13:49:58

newest version of msmtp not working

#2 2012-04-06 15:28:49

Re: newest version of msmtp not working

#3 2012-04-06 18:17:23

Re: newest version of msmtp not working

#4 2012-04-06 20:01:39

Re: newest version of msmtp not working

#5 2012-06-06 12:54:41

Re: newest version of msmtp not working

Board footer