hit authentication problem when alert mail password has special character

[#1]

I'm using alert publisher in Cloudera Express 5.9.0.

I did the mail configuration and I'm sure username and password are all corrrect.  But my password contains "%", and found the alert publisher service can not start with the error "Illegal hex characters in escape (%) pattern", I have to input "%25" to the password field to make the service start.

When sending test alert mail,  hit "AuthenticationFailedException: 535 5.7.3 Authentication unsuccessful".

The password in alertpublisher.conf is encryped, I can not find which password the service is using for communting with mail server. 

Can someone tell me how to make such password work? Thanks a lot!!

[#2 · Accepted solution]

@dinoma,

What you tried sounds like the right thing, but perhaps there are other characters in the string that don't stop the server from starting, but prevent the password from being passed to the SMTP server properly.

You can use this to print out an escaped version of the password to enter into the "Mail Server Password" field:

# python -c "import urllib,sys; print urllib.quote_plus(sys.argv[1])" "p%ss+word!"

Replace the training string in quotes with your literal password (no escaping).

For example, the above command would result in:

p%25ss%2Bword%21

Cloudera has a Jira open for this issue, but we don't have a fix for it yet.

[#3 · Accepted solution]

@dinoma,

What you tried sounds like the right thing, but perhaps there are other characters in the string that don't stop the server from starting, but prevent the password from being passed to the SMTP server properly.

You can use this to print out an escaped version of the password to enter into the "Mail Server Password" field:

# python -c "import urllib,sys; print urllib.quote_plus(sys.argv[1])" "p%ss+word!"

Replace the training string in quotes with your literal password (no escaping).

For example, the above command would result in:

p%25ss%2Bword%21

Cloudera has a Jira open for this issue, but we don't have a fix for it yet.

[#4]

Thanks for the reply and the information.
I tested with two mail addresses, one can work well with the escaped version password, the another is a public mail and can not work with “AuthenticationFailedException: 535 5.7.3”. Our mail admin has checked the privileges are same. The only difference is the password. The public one has many special characters. Could you please share some tips on such authentication error? Thanks again.

[#5 · Accepted solution]

@dinoma, Authentication errors don't often tell us more than that the authentication failed.  Assuming the password is correctly encoded for a URL, some other possibilities to check:

- The password supplied is not correct in some way.  You could verify the smtp password by using telnet and manually typing in the non-encoded password to make sure it is correct

- The encoding didn't work as expected so the resulting encoded password was not correct due to shell interpretation or something.  You could try this to see if it changes the resulting encoded password:

Create a new file containing the plain text, non-encoded password

# vi ~/password_file

Strip off the trailing return character:

# echo -n ~/password_file > ~/password_file2

Encode the password:

# python -c "import urllib,sys; print urllib.quote_plus(sys.argv[1])" `cat ~/password_file2`

[#6]

Thanks a lot, my problem is fixed by using the escapted version of password.