Special characters in ssmtp password

14

1

I have + and = characters in my gmail password. How can I configure ssmtp to avoid authorization error?

My /etc/ssmtp/ssmtp.conf:

root=username@gmail.com
mailhub=smtp.gmail.com:465
rewriteDomain=gmail.com
AuthUser=username
AuthPass=1234+=5678
FromLineOverride=YES
UseTLS=YES
hostname=skynet

How do I run ssmtp:

$ echo "email content" | mail -s "email subject" otherMail@gmail.com
send-mail: Authorization failed (535 5.7.1
http://support.google.com/mail/bin/answer.py?answer=14257
hz16sm4385885lab.6)

Jofsey

Posted 2012-06-01T17:43:34.257

Reputation: 917

Did you try single quotes, that should work for you – Suyash Jain – 2016-06-26T16:56:12.090

The bug is at https://github.com/ajwans/sSMTP/blob/master/ssmtp.c#L913, I remember I submitted a patch back in 2010...nobody cares. I guess it is a feature, rather than a bug!

– David S. – 2018-09-17T03:24:17.210

1What program does the error occur in? Please give us some context. Brevity is good, but this is little to work on. – user 99572 is fine – 2012-06-01T17:54:37.703

I've attach some more information to the question. – Jofsey – 2012-06-01T19:45:46.380

Answers

5

There are still a number of outstanding bugs dealing with special characters on the AuthPass line in the /etc/ssmtp/ssmtp.conf file:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=ssmtp#_0_3_4

These bug reports are specifically for the ssmtp page in Debian, but probably apply to others.

  • Debian Bug report logs - #463196: ssmtp cannot parse AuthPass with '=' or ':' in it
  • Debian Bug report logs - #768129: ssmtp: Same problem here with "#"

According to these report logs, lines containing the characters =, :, or # are either skipped entirely, or processed in a way that removes the part of password on the right-hand side these characters.

In other words, there is currently no way to "escape" these special characters on the AuthPass line.


As a side note, there are a number of devices, such as wireless home printers, that require passwords to be entered on a number pad, similar to those used on telephones. Some special characters are available on these devices, but many cannot be selected.

For situations like this, you are (unfortunately) forced to adjust your password for the device.

A longer password consisting of letters & numbers is preferred to a shorter one with more punctuation characters.


This question has also been asked and answered very well on the following page:

What characters are illegal in password in ssmtp.conf?

JonathanDavidArndt

Posted 2012-06-01T17:43:34.257

Reputation: 890

@Hugo That may be a good topic for another question: https://superuser.com/help/how-to-ask If you find something or post your own, feel free to leave another comment here linking to it.

– JonathanDavidArndt – 2019-05-22T01:05:00.237

The maintainers should consider treating the config file entry as Urlencoded like in some other packages. – Old Geezer – 2019-06-13T09:05:24.373

1

You can use the following workaround:

feed the password directly in the command line argument

ssmtp -ap "Hash#Password" ...

alternatively put the password in an environment variable.

ssmtp -ap $PASSWD ...

Hope it helped.

Hugo Trentesaux

Posted 2012-06-01T17:43:34.257

Reputation: 111

-1

Try escaping the second equals sign:

AuthPass=1234+\=5678

Malcolm Boekhoff

Posted 2012-06-01T17:43:34.257

Reputation: 97

-1

The answer highly depends on the context in which you are entering or submitting the password. In some formats, you can surround your password in ""'s, in others you would need to escape the offending characters. This escape character, differs between programs, shells, Operating systems, etc. In Windows batch scripts the escape is ^ while in certain Linux or terminal situations, the escape is \.

PenguinCoder

Posted 2012-06-01T17:43:34.257

Reputation: 628

1The context is the ssmtp package, not SMTP in general. – Kenny Evitt – 2016-12-15T23:49:04.227

1I tryed to store my password in 1234\+\=5678 form, but got the same error. – Jofsey – 2012-06-01T19:47:35.313