First let me state that the mail server is working fine and users can connect and send email.

Basically there is a local web script connecting into the mail server trying to send mail every few minutes. It has the wrong password. Problem is we don't know what script is connecting in so we are looking for a way to get the username which is being tried.

UGFzc3dvcmQ6 - decodes to Password: so isn't much help. A full log line is below.

Dec 11 20:15:37 HOST postfix/smtpd[642]: warning: HOST[x.x.x.x]: SASL LOGIN authentication failed: UGFzc3dvcmQ6

Server is running Debian/Postfix/Dovecot.

  • 6
    I have the very same logs. The IP address alway changes, and requests are coming in from all over the world. It it more likely a break in attempt.
    – nagylzs
    Sep 13 '16 at 5:51
  • 5
    Good old UGFzc3dvcmQ6. Still trying to log in to my server from all over too after all these years. Just have to ignore it. Dec 16 '18 at 9:16
  • 2
    UGFzc3dvcmQ6 is 'Password' encoded in base64, I also see 'VXNlcm5hbWU6' which is 'Username' - been like that for years.
    – Jason M
    Oct 22 '19 at 16:48

We were able to trace the username by using Dovecot itself.

In the /etc/dovecot/conf.d/10-logging.conf config we enabled verbose auth logging using

auth_verbose = yes

This put the information in

  • Shouldn't the log be in /var/log/dovecot-info.log?
    – Chloe
    May 8 '16 at 23:52
  • 1
    Mine is in syslog
    – ISparkes
    Nov 3 '17 at 7:04
  • This method won't always work - depending on how you setup things / how sasl and auth are done. Best to debug postfix if that is where you see bad auths. Debug peer list is best answer I've found. (below). It can also give you the LAN ip of client if that helps.
    – B. Shea
    Oct 21 '20 at 18:08

I was able to prevent this by setting up SSL and requiring auth attempts over SSL only with

smtpd_tls_auth_only = yes

This doesn't present the AUTH option to the remote client after EHLO and so the spammers/hackers give up because establishing a SSL connection is too much time. They work a numbers game. Now instead it hangs up when they try AUTH and I get this in my logs:

Jan  7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: warning: hostname vps863.hidehost.net verification failed: No address associated with hostname
Jan  7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: connect from unknown[]
Jan  7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: lost connection after AUTH from unknown[]
Jan  7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: disconnect from unknown[]
  • TLS is so cheap now that they try even after TLS only auth enabled.
    – Braiam
    May 17 '20 at 1:47
  • I had similar issue with SASL by setting that flag it's gone. and Yes now I'm having connect/disconnect issue for a unknown IP. what you did for that to fix? Feb 6 at 3:49

If you have fail2ban installed you can enable sasl (or sometimes called postfix-sasl) in your jail.local (or jail.d) and that should make the annoyances go away.

## for me this is in /etc/fail2ban/jail.d/defaults-debian.conf
enabled = true

enabled = true

There are at least two ways of finding the user name(s) being tried.

Logging SMTP transactions with Postfix

If you know which host(s) your strange connections are coming from, you can enable verbose debugging for them by specifying a debug_peer_list in /etc/postfix/main.cf:

debug_peer_list =

This will yield, among other things, a message like this in syslog:

postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: FAIL?5?user=info

You will want to use this setting for very specific debugging only, since the full SMTP session is logged, including the password.

postfix/smtpd[123]: < unknown[]: AUTH LOGIN
postfix/smtpd[123]: xsasl_dovecot_server_first: sasl_method LOGIN
postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: CONT?5?VXNlcm5hbWU6
postfix/smtpd[123]: > unknown[]: 334 VXNlcm5hbWU6
postfix/smtpd[123]: < unknown[]: aW5mbw==
postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: CONT?5?UGFzc3dvcmQ6
postfix/smtpd[123]: > unknown[ 334 UGFzc3dvcmQ6
postfix/smtpd[123]: < unknown[]: Zm9vYmFy
postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: FAIL?5?user=info
postfix/smtpd[123]: warning: unknown[]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
postfix/smtpd[123]: > unknown[]: 535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6

In this example, a LOGIN attempt for user "info" has failed after the password "foobar" was presented. Like the challenges, you can decode the replies as base64:

$ echo aW5mbw== | echo $(base64 -d)
$ echo Zm9vYmFy | echo $(base64 -d)

Logging authentication with Dovecot

Postfix itself does not include a SASL implementation. Traditionally, it was hooked up to Cyrus SASL, but if you are using the Dovecot POP/IMAP server, Postfix can reuse its SASL module.

As you have found out, Dovecot has its own debugging facility, enabled with

auth_verbose = yes

in its config file, often /etc/dovecot/conf.d/10-logging.conf. The output in /var/log/dovecot-info.log will look something like this:

Jun 10 13:16:40 auth-worker(14936): Info: pam(info@example.com, pam_authenticate() failed: Authentication failure (password mismatch?)

While there is no host-based control here, there are a number of related options to control what gets logged, specifically whether or not to include the attempted passwords. From the example config:

# Log unsuccessful authentication attempts and the reasons why they failed.
auth_verbose = no

# In case of password mismatches, log the attempted password. Valid values are
# no, plain and sha1. sha1 can be useful for detecting brute force password
# attempts vs. user simply trying the same password over and over again.
auth_verbose_passwords = no

# Even more verbose logging for debugging purposes. Shows for example SQL
# queries.
auth_debug = no

# In case of password mismatches, log the passwords and used scheme so the
# problem can be debugged. Enabling this also enables auth_debug.
auth_debug_passwords = no

See also the Dovecot documentation for details.

About SMTP authentication

As you note, the string UGFzc3dvcmQ6 in the log message is the base64-encoding of "Password:". What Postfix is logging here is the particular authentication "challenge" that it has sent and received an erroneous reply for. There is also a preceding challenge for "Username:" (VXNlcm5hbWU6). However, even for nonexistent users, the failure will only be reported after the password.

The values of the challenge strings are actually unimportant and should be ignored. The first challenge is always for the user name, and the second is for the password. The details about this can be found in the specification for the LOGIN method.

NB: Since this is all a bit noodly for just transfering and checking the username-password pair, LOGIN is long obsoleted. The PLAIN method works essentially the same but packs both pieces of information into the same base64 string.

Finally, the fact that parts of this conversation are base64-encoded is actually a feature of SMTP Authentication in general. The idea is to easily allow arbitrary (possibly binary) data to be exchanged between the SASL modules of client and server, without those SASL modules needing to know or care about SMTP itself. You can get an idea of how SASL operates from the Cyrus SASL documentation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.