Broken Postfix+Dovecot+MySQL?

CopalFreak · 01-05-2012, 03:31 AM

I think I have something wrong in my Postfix (possibly SASL) setup.

I can send/receive emails from some clients (like Thunderbird and outlook express) using port pop-995 and smpt-587 with the settings 'requires authentication'.
However, clients like Windows Live Mail and Outlook 2010 (even though they are supposed to support both TLS and SSL) refuse to 'authenticate' with these settings.
(but can send/receive still..just not authenticate...which means with my current settings, users outside 'mynetworks' are not be able to send even though they are valid users (virtual users via MySQL that is).

I suspect the problem is that I may not have compiled postfix correctly with sasl login support.

when I telnet to port 587
I see "250 starttls" but no login or plain or anything like that.

Is there a way to definitivly test if I do or do not have the support built in to use 'authentication' to allow users to send mail from a non-local location?

I am pretty new to this stuff so I am not quite sure if I am doing this correctly..

As I understand it so far...

SSL is for encrypting traffic between client and server and (with a cert on both sides) could be used for authentication.

SASL is for identificaton/authentication. once validated, it would allow users to use the mail server (permit_sasl_authenticated setting in postfix conf )

TLS is kinda like a newer version of SSL and can be used to both authenticate and encrypt, but some clients do not support it.

A combination of both SASL and TLS should support all (or at least most) email clients and the typical ports used would be 995 for incoming and 587 for outgoing.

Is that correct?

when doing an nmap I see ports 25(smtp), 110(pop3), 113(auth), 143(imap), 465(smtps), 587(submission) 993 (imaps), and 995 (pop3s).

Before putting this on the internet, I want to make sure that it only allows sending/relaying mail for authenticated users only (non-open relay), and (if possible without an SSL cert on the client side) to have encryption for traffic to and from client/server. (have a valid cert).

I shouldn't need to post any configs for this one, as the questions are pretty generic...

1: is my current understanding of TLS/SASL/SSL correct?

2: since I dont see any 'login' type things with telneting in, is that any clear indicator that I may be missing some sort of TLS and/or SASL thing in my postfix?

3: Is there a way to 're-do' postfix to add sasl/tls login support (if thats what I need) without messing up the current 'semi-working' one?

I have 1 more computer that I can do a fresh install on if it would be easier, but I would really prefer it if I could 'fix' this one as I think I will learn more about it that way. (will probably start over again later, once I have a better idea of whats going on anyway...just don't want to lose my working setup until I have a better one, or at least know what I am doing so that I could set it up from scratch and have it work.)

Thanks a ton for any response.

rhbegin · 01-06-2012, 01:01 PM

Can you try it without using mysql?

leslie_jones · 01-06-2012, 01:47 PM

Authentication -v- Encryption are two distinctive and different things as you point out.

Forget the TLS/SSL/ENCRYPTION for a moment and consider that you AUTHENTICATE with SASL. You don't technically need any encryption, but because the SASL login sequence (of type 'plain' or 'login' et al) is trivial to sniff and de-mung, sensible servers set up ENCRYPTION before sending the login, but strictly speaking this is not necessary and SASL works fine without it. So you are right on the money with how you understand this.

As for Encryption we either initially use a clear text connection and issue the START-TLS to begin the encryption, or have the server listen on a dedicated separate port for TLS encrypted connections (START-TLS does not figure here, the overall connection is secured instead as it is set up).

This is typically where clients crap the bed a bit - particularly of the Microsoft variety. My memory is shaky, and Google will be your friend here, but IIRC Microsoft decided to use some non standard port for secure connections (465 rings a bell), whereas dedicated TLS submission is normally made on port 587. Both of these cases should require/create a secure connection ahead of any SMTP commands, effectively securing the login phase of SMTPAUTH/SASL.

I think the non-standard port issue may no longer be an issue, but Google may hint at other issues with M$ clients. I'd personally check the port assignment in the client and if it's 465/587 and alternate between the SSL/TLS settings. I had a client once that tried to issue a START-TLS when 'TLS' was selected, despite the channel being already secured.

When I was working on this stuff I found a couple of resources helpful and I hope they may help you, and ways to test it:

http://qmail.jms1.net/test-auth.shtml
http://www.madboa.com/geek/openssl/ [scroll to How do I connect to a secure SMTP server?]
http://www.postfix.org/TLS_README.html (note the logging options)

Quote:

TEST START-TLS ON PORT 25
# port 25/TLS; use same syntax for port 587
openssl s_client -connect remote.host:25 -starttls smtp

# port 465/SSL
openssl s_client -connect remote.host:465

Hope this is of some use to you.

lithos · 01-06-2012, 02:07 PM

Hi,

could this be helpful to you.
I read only about
postfix main.conf:
"broken_sasl_auth_clients = yes" allows Outlook users to Auth with TLS (i think) otherwise not.

As I'm running similar setup on my mail server as you , I'm also looking onto how to do it.

good luck

CopalFreak · 01-06-2012, 11:59 PM

Quote:

Originally Posted by rhbegin

Can you try it without using mysql?

I could, but I suspect the results would be the same.
I am not having a problem with validating user, and can send/receive email using pop3-110 and smtp-25.
It's only when trying to use ports 995(pop) and either 465 or 587 and ONLY with Outlook 2010 and Windows Live Mail that I run into problems.
(older Outlook Express, latest Mozilla Thunderbird work fine).

CopalFreak · 01-07-2012, 12:02 AM

Quote:

Originally Posted by lithos

Hi,

could this be helpful to you.
I read only about
postfix main.conf:
"broken_sasl_auth_clients = yes" allows Outlook users to Auth with TLS (i think) otherwise not.

As I'm running similar setup on my mail server as you , I'm also looking onto how to do it.

good luck

I do have that turned on in my main.conf, but it doesn't seem to be doing any good.
I think that the it probably 'would' if I had SASL setup correctly.
If I get it working, will be sure to post what the problem was and what I did to fix it.

CopalFreak · 01-07-2012, 02:12 AM

Quote:

Originally Posted by leslie_jones

Authentication -v- Encryption are two distinctive and different things as you point out.

Forget the TLS/SSL/ENCRYPTION for a moment and consider that you AUTHENTICATE with SASL. You don't technically need any encryption, but because the SASL login sequence (of type 'plain' or 'login' et al) is trivial to sniff and de-mung, sensible servers set up ENCRYPTION before sending the login, but strictly speaking this is not necessary and SASL works fine without it. So you are right on the money with how you understand this.

As for Encryption we either initially use a clear text connection and issue the START-TLS to begin the encryption, or have the server listen on a dedicated separate port for TLS encrypted connections (START-TLS does not figure here, the overall connection is secured instead as it is set up).

This is typically where clients crap the bed a bit - particularly of the Microsoft variety. My memory is shaky, and Google will be your friend here, but IIRC Microsoft decided to use some non standard port for secure connections (465 rings a bell), whereas dedicated TLS submission is normally made on port 587. Both of these cases should require/create a secure connection ahead of any SMTP commands, effectively securing the login phase of SMTPAUTH/SASL.

I think the non-standard port issue may no longer be an issue, but Google may hint at other issues with M$ clients. I'd personally check the port assignment in the client and if it's 465/587 and alternate between the SSL/TLS settings. I had a client once that tried to issue a START-TLS when 'TLS' was selected, despite the channel being already secured.

When I was working on this stuff I found a couple of resources helpful and I hope they may help you, and ways to test it:

http://qmail.jms1.net/test-auth.shtml
http://www.madboa.com/geek/openssl/ [scroll to How do I connect to a secure SMTP server?]
http://www.postfix.org/TLS_README.html (note the logging options)

Hope this is of some use to you.

Not sure I quite understand...
so I only need EITHER 465 OR 587 open, but not both?
And if its 465, that's TLS and plain_text auth is OK?
and if its 587, that's just a 'dedicated' port for SSL+TLS but does the same thing?

Is that right?

As mentioned when I telnet in (like the example from your first link), I DO see "250-STARTTLS"
but do NOT see "250-AUTH LOGIN PLAIN" or "250-AUTH=LOGIN PLAIN"
which makes me thing saslauthd is not running...but a quick 'ps ax | grep [s]asl' shows

Code:

/usr/sbin/saslauthd -a rimap -n 3 -O localhost
smtpd -n submission -t inet -u -o smtpd_tls_security_level may -o smtpd_sasl_auth_enable yes -o smtpd_sasl_type dovecot -o smtpd_sasl_path /var/spool/postfix/private/auth -o smtpd_sasl_security_options noanonymous -o smtpd_sasl_local_domain $myhostname

If I set the smtp to port 465 with STARTTLS in Thunderbird, it works fine and the maillog shows

Code:

postfix/smtpd(xxxxx): connect from {ip}
postfix/smtpd(xxxxx): setting up TLS conenction from {ip}
postfix/smtpd(xxxxx): TLS connection establish from {ip}: TLSv1 with cipher {...}
postfix/smtpd(xxxxx): client={ip}, sasl_method=PLAIN, sasl_username={my-username}
postfix/cleanup(xxxxx): message-id=xxxxx
postfix/qmgr(xxxxx): from=<my_sending_email_address>, size=712, nrcpt=1 {queue active)
postfix/smtpd(xxxxx): disconnect from {ip}
postfix/smtpd(xxxxx): to=<recipient_email_address>, relay=outside.relay,....status=sent

(STARTTLS is not an option in Outlook 2010..but TLS and SSL/TLS are options..could that be part of the problem?)

if I set it to 465 and SSL/TLS, I can see it connect, but it thunderbird times out, and maillog shows

Code:

connect from {ip}
lost connection after UNKNOWN from {ip}
disconnect from {ip}

Thanks a ton for your help!
I will continue to google, but so far, you seem like my best hope.
(if we get it working, I shall call you 'obi wan'! hehe)

leslie_jones · 01-07-2012, 06:28 AM

First of all, don't necessarily assume I'm correct - I'm working from notes I made a number of years ago. However I have fired up a copy of Outlook 2007 (it's all I have) and made sure it works with my Postfix, but I don't have 2010/Mail 2010 to test]. I encountered a couple of minor problems, but these were all client settings and once I'd found where things like TLS/SSL were hidden in 2007, it started to work without any flaws. I've grabbed a couple of screenshots because I was surprised at how many gui hoops I had to jump through with M$ to set simple things up like TLS, authentication and outbound port.

http://www.fotobytes.co.uk/user81807...ook2007_00.jpg
http://www.fotobytes.co.uk/user81807...ook2007_01.jpg

I'd take the client account configuration to bits making sure I'd specified port 587 and TLS plus the full, correct username and password. I'd also check I was using PLAIN or LOGIN and not accidentally selected any fancy CRAM / DIGEST methods. I'd also make sure I'd not checked "require login using Secure Password Authentication (SPA)"

As I understand it, there USED to be an issue with some Microsoft clients and their use of port 465 [Possibly something to do with Exchange, so don't get hung up on this]- which Postfix refers to in it's MASTER.CF (not main.cf) as 'smtps'.

For these old clients it was just a case of enabling 'broken_sasl_auth_clients' in main.cf, after having set up MASTER.CF to listen on port 465 for SSL connections. SMTPS seems to work by establishing and SSL connection FIRST (no start-tls here), once the channel is up, it is encrypted, so AUTH data can be sent without too much fear of sniffing. For completeness I've shown the relevant parts of MASTER.CF for port 465, I've left a couple of options commented out as they are either duplicated in main.cf, or not required in the context I was testing in

Code:

MASTER.CF (more at http://www.postfix.org/master.5.html)
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
#change outbound listening port
smtp      inet  n       -       -       -       10       smtpd
#submission inet n       -       -       -       -       smtpd
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

IMPORTANT!
This is probably old, legacy info which is no longer relevant. I say this because my test Outlook 2007 (itself a number of years old) can be set up to work with outbount SMTP on any port using either TLS or SSL. I've checked it with submission (587) and 25 using start-tls and it is flawless with my setup but I stress, this is 2007 - not 2010. The Master Settings I have are:

Code:

smtp      inet  n       -       -       -       10       smtpd
submission inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

Testing is straightforward and I would recommend doing this by hand so you know the install is OK, and to isolate the problem to the client. The process is to connect and encrypt the channel, then submit the AUTH details and we can do this from a Linux box with a recent openssl implementation:

SUBMISSION (587) or SMTP (25) use the same process but be aware that it is common to block 25 for AUTH nowadays:
openssl s_client -connect server.name.or.ip:587 -starttls smtp

If all is well, it will spit out various encryption info and deliver you to a Postfix status code 250 DSN.
Enter: "EHLO ." (no quotes) and you'll see something like this:
...

Code:

250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
...

Here we can see we can now AUTHENTICATE using plain or login methods.
To use PLAIN we need to create a PLAIN auth string. This is formed from the identity to login as, followed by a US-ASCII NULL character (\0 in the following example), followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NULL character, followed by the clear-text password. This is then base64 encoded.

Say the credentials are

USER: johnsmith
PASS: secret

We can create the plain auth string in a terminal like this:

Code:

printf 'johnsmith\0johnsmith\0secret' | openssl enc -base64
am9obnNtaXRoAGpvaG5zbWl0aABzZWNyZXQ=

To use it, we connect to the server like we did above, issue the "EHLO ." then use the PLAIN method by entering:
AUTH PLAIN am9obnNtaXRoAGpvaG5zbWl0aABzZWNyZXQ=
If all is well we should get back something like: 235 2.7.0 Authentication successful

The LOGIN method is slightly different.
Create BASE64 versions of the username and password

Code:

printf 'johnsmith' | openssl enc -base64
am9obnNtaXRo
printf 'secret' | openssl enc -base64
c2VjcmV0

After connecting to to the server and issuing "EHLO .", issue 'AUTH LOGIN'.
The server should respond 334 VXNlcm5hbWU6' where 'VXNlcm5hbWU6' is a BASE64 encoded string 'Username:'
Enter the base64 username, hit enter, server should respond 334 UGFzc3dvcmQ6' (base64 password

, enter the base64 password
and you should log in:

Code:

auth login
334 VXNlcm5hbWU6
am9obnNtaXRo
334 UGFzc3dvcmQ6
c2VjcmV0
235 2.7.0 Authentication successful

For testing the SMTPS port (465) it's the same, apart from you use: "openssl s_client -connect server:465" (no starttls).
But like I say, I doubt you need that in this day and age.

My advice would be make sure your Postfix works for submission on 587 flawlessly by hand. Once you've done that, should you find any client failing to work and you can't find why consider using TCPDUMP/Wireshark and see if it gives any clues.

Hoping this helps you in some way.
Leslie

CopalFreak · 01-11-2012, 11:37 AM

Thank you SO much Leslie!
This is exactly what I was looking for!

Port 25 works now, as does 465...but not port 587.

When I do "openssl s_client -connect 192.168.1.97:587 -starttls smtp"
it just says

Code:

CONNECTED(00000003)

nothing after that. Doing 'ehlo' does nothing.

maillog says "SSL_accept error : 0"

Code:

connect from 192.168.1.97
setting up TLS connection from 192.168.1.97
SSL_accept error from 192.168.1.97 : 0
lost connection after Connect 192.168.1.97
disconnect from 192.168.1.97

If I just do

Code:

#openssl s_client -connect 192.168.1.97:587

(without the estarttls smtp)
it lets me in and I can 'ehlo'.

Also, on another machine(we can call it Machine2 or M2), when I do "openssl s_client -connect {host}:587",
it lets me in, but says "Verify return code:20 (unable to get local issuer certificate)"
when I do "ehlo" it does NOT list

Code:

250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN

but instead, only says

Code:

250-mail.{myMail}
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Any clues as to how to finish up Machine1(M1), and what might be wrong with M2?

Thanks!!

leslie_jones · 01-11-2012, 12:53 PM

I've not had these problems myself, so what I'm saying is based on guesswork and may be plain wrong.
However,

Code:

SSL_accept error from server1.domain.org[11.22.33.44]: 0

Suggests a connection type mismatch with the client (in this case openssl) which is a bit weird.

I can't make up my mind if this is a simple config issue in master.cf, main.cf or a certificate issue. I'd be inclined to post your question/problem to the Postfix Users Mailing list (details on how to join it are here: http://www.postfix.org/lists.html) where you should get the correct answer. Not only is the author of Postfix on that user list, but the experts Ralf Hildebrandt and Patrick Koetter who wrote 'The Book Of Postfix' regularly post there and answer questions too. They can be a little bit 'prickly' and blunt, but if they can't solve this for you then nobody else can!

CopalFreak · 01-11-2012, 10:51 PM

It looks like a config error..i think..
And thanks to you, I THINK it's working...I think..
(I just needed to be pointed in the right direction! hehe)

I fout out I was missing the "smtpd.conf" file.

Code:

#/etc/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login

(not really sure if that was causing anything, as it may be covered elsewhere)

The openssl commands I used that worked are slightly different (openssl-0.9.8r).
openssl s_client -connect 192.168.1.97 (works..defaults to tls1)
openssl s_client -connect 192.168.1.97:25 (works..defaults to tls1)
openssl s_client -connect 192.168.1.97:465 (works..defaults to tls1)
openssl s_client -connect 192.168.1.97:587 -tls1 (works)
openssl s_client -connect 192.168.1.97:587 -ssl2 (fails with "write:errno=104" **)
openssl s_client -connect 192.168.1.97:587 -ssl3 (works)

** when tryin SSLv2:
I found out that using SSLv2 may cause problems, so they are disable by default and that is what was cauing my error.
In the main.com there is a directive that says "!SSLv2" in an attempt to get rid of it.
But in the newer postfix, where its off by default, putting that it causes problems.

for more info on how to disable :
http://adamyoung.net/Disable-SSLv2-System-Wide .

I can "ehlo Me" and "AUTH PLAIN BlahBlahBlah..."

It says :

Code:

"235 2.7.0 Authentication successful"

YAYYY!!

The Maillog shows

Code:

Anonymous TLS connection estatblished from {host-ip}: TLSv1{or SSLv3} with cypher DHE-RSA-AES256-SHA (256/256 bits)

The dovecot-info.log (dovecot.conf has all debugs set to yes for the moment)
shows (when I do the "AUTH PLAIN ..."from the console)

Code:

auth: Debug: auth client connected (pid=xxxx)
auth: Debug: client in: AUTH 1 PLAIN service=smtp nologin lip={ip} rip={ip} secured resp={authKey}
auth: Debug: sql({sql query here to make sure user is valid and active}):
auth auth: Debug: client out: OK 1 user = {username}

It LOOKS like it's working..I am so stunned, that I am looking just to make sure it really is.. lol!

On the other server (M2), I still don't see PLAIN or LOGIN, but now, it let's me in and let's me authenticate.

It does however, show this error :

Code:

"Verify return code: 21 (unable to verify the first certificate)"

But lets me authenticate anyway (because encrypt = may? or ssl certs not 'mandatory' maybe?)

I think I just need to re-do the certs to get the error to go away.
(will do that this weekend and if it works, will post steps and marked as solved)

Is there some sort of 'stealthing' or hiding of services that might be turned on that would prevent AUTH PLAIN and LOGIN from showing up?
(I think I read about a "private" setting that sounded like it might do that, but I can't remember where it would be)

getting closer!!..almost..there!

Thanks again!