# Is dovecot SASL is working dovecot+postfix+SASL+TLS

## methodtwo

Hi

I want to be able to send and receive email to/from servers in my DMZ, and allow relaying through my postfix MTA via SASL+TLS.

When i open mutt from one of my clients, on my internal network dovecot asks me for my authentication credentials. Then i enter them and it says its using TLS. This is the behavior i want from dovecot(it doesn't matter about self signed certs etc) . Then if i go to send a mail to a user on my postfix server it says that the connection is using TLS, but it asks for no authentication credentials.

My postfix server is using dovecot SASL. So i was wondering: is SASL failing for postfix or is postfix not asking for any credentials due to the fact that i'm using dovecot SASL and i've already sent my credentials to dovecot?

Also mutt uses STARTTLS so it's "turning it on after the fact" so to speak. Should i disable TLS on postfix and test SASL first? What is the command to test SASL with AUTH PLAIN when testing with telnet? Is it

```
 AUTH PLAIN plain_text_password 
```

 ?

Thanks for any advice or light shedding

regards

----------

## cach0rr0

postfix is probably not asking for auth, because you're connecting from within the same LAN as the postfix server

more specifically, you've probably set up $mynetworks to be something like so:

```

mynetworks = 192.168.0.0/16, 127.0.0.0/8

```

and then within smtpd_recipient_restrictions, you probably have something like:

```

smtpd_recipient_restrictions =

        permit_mynetworks,

        permit_sasl_authenticated,

        reject_unauth_destination

```

The first line will permit mail from hosts in $mynetworks regardless of the destination

As far as testing ESMTP authentication on Postfix, first thing to do: take your username, base64 encode it. Take your password, base64 encode it. (link to b64 encoder) Write this down in notepad or wherever, then connect (using SSL) like so and test:

```

openssl s_client -connect 192.168.1.25:25 -starttls smtp

EHLO test.com

AUTH LOGIN

```

once you issue AUTH LOGIN and hit enter, you'll see a 334 VXNlcm5hbWU6. That's base64 text, which when decoded says "Username:". This is where you enter your username. It should then prompt you for the password, albeit with base64 text - you enter your base64 encoded password. 

It looks something like so (I've denoted commands you type with "TX:" and commands you receive from the server with "RX:"):

```

TX: openssl s_client -connect renee.whitehathouston.com -starttls smtp

RX: 250 DSN

TX: EHLO ricker.whitehathouston.com

RX: 250-renee.whitehathouston.com

RX: 250-PIPELINING

RX: 250-SIZE 100000000

RX: 250-VRFY

RX: 250-ETRN

RX: 250-AUTH LOGIN PLAIN

RX: 250-AUTH=LOGIN PLAIN

RX: 250-ENHANCEDSTATUSCODES

RX: 250-8BITMIME

RX: 250 DSN

TX: AUTH LOGIN

RX: 334 VXNlcm5hbWU6

TX: dGVzdEB0ZXN0LmNvbQ==

RX: 334 UGFzc3dvcmQ6

TX: cGFzc3dvcmQ=

```

When you base64 encode "test@test.com", it becomes "dGVzdEB0ZXN0LmNvbQ=="

When you base64 encode "password", it becomes "cGFzc3dvcmQ="

This is more or less how auth logins work under SMTP. If successful, you would get a message back from postfix that says something like "250 Authenticated" at which point you do your usual:

```

TX: MAIL FROM:<user@senderdomain.com>

RX: 250 Ok

TX: RCPT TO:<user@recipientdomain.com>

RX: 250 Ok

TX: DATA

RX: 354 Go Ahead

TX: From: "Me" <user@senderdomain.com>

TX: To: "You" <user@recipientdomain.com>

TX: Subject: This is a test

TX: 

TX: This is the message body

TX: .

RX: 250 Message Accepted for Delivery

TX: QUIT

RX: 250 Goodbye!

```

Why did I do this using openssl s_client? Because the assumption is made you are only allowing people to auth to Postfix if they've connected via TLS (smtpd_tls_auth_only = yes in main.cf)

If you set smtpd_tls_auth_only = yes, then you will not see the "AUTH" extension as a response to your EHLO, unless you've first established a TLS session with Postfix - now, the trick is, if you're in $mynetworks, and you've set permit_mynetworks, it won't matter that you don't see the AUTH and therefore cant provide auth, because you're permitting mail from $mynetworks regardless of whether or not they've authenticated via sasl

In terms of what backend SASL uses to verify the password, that isn't controlled by main.cf, but rather by /etc/sasl2/smtpd.conf (which is where you tell it to use Dovecot, Cyrus, mysql, whatever)

Hope that helps or clarifies, holler if you have any questions.

----------

## methodtwo

Thank you very much for such an informative reply. I have only one remaining question: When you enable TLS in postfix will it automatically try to be an SMTP client that wants to connect to my I.S.P's server using TLS? I guess it totally depends on how my I.S.P's MTA is set up? If my MTA does try to STARTTLS to my i.s.p's MTA and my I.S.P's MTA refuses to honor this then my MTA will default to normal SMTP? Or do connections between MTAs always happen in the clear?

----------

## cach0rr0

 *methodtwo wrote:*   

> When you enable TLS in postfix will it automatically try to be an SMTP client that wants to connect to my I.S.P's server using TLS? 

 

settings prefixed with "smtpd_" relate to mail that postfix *receives* (acting as an SMTP server)

settings prefixed with "smtp_" relate to mail that postfix *sends* (acting as an SMTP client)

One thing to note, the settings you put into main.cf are not the *only* settings Postfix uses; they are replacements for defaults. Think of it along the lines of Postfix having its own hidden main.cf that it will normally use, unless you specify overrides in /etc/postfix/main.cf. You can see the defaults by keying in "postconf -d" on the command-line. 

To save you some time, by default Postfix will attempt to send via TLS if the server it is connecting to supports it. 

 *methodtwo wrote:*   

> 
> 
> I guess it totally depends on how my I.S.P's MTA is set up?
> 
> 

 

Correct, however it's quick enough to see if your ISP's MTA is set up to support STARTTLS. Simply connect on port 25 via telnet, and issue an EHLO (not a HELO - STARTTLS is an SMTP extension, not part of the original SMTP protocol, and in order to see which extensions an MTA supports, you have to issue an EHLO rather than a HELO, as the EHLO tells the remote MTA 'hey, i support a few extensions, can you show me yours to see if we support the same ones?')

 *methodtwo wrote:*   

> 
> 
> If my MTA does try to STARTTLS to my i.s.p's MTA and my I.S.P's MTA refuses to honor this then my MTA will default to normal SMTP? 
> 
> 

 

Your MTA will not try to do STARTTLS unless the ISP's MTA advertises support for it. See above regarding how to test. 

If your ISP's MTA does not support STARTTLS, then it will not show this as one of the support extensions when you issue an EHLO. 

fourth from the bottom:

```

# telnet localhost 25

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

220 renee.whitehathouston.com ESMTP Postfix (2.6.5)

EHLO there

250-renee.whitehathouston.com

250-PIPELINING

250-SIZE 100000000

250-VRFY

250-ETRN

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

```

 *methodtwo wrote:*   

> 
> 
> Or do connections between MTAs always happen in the clear?

 

When sending a message, Postfix will attempt to use TLS if the remote MTA supports it. 

A message will be sent in the clear under the following circumstances:

-you've specifically configured Postfix to do so

-the remote server does not support ESMTP at all, which would mean the EHLO fails (RFC-compliant servers that see a failure reply to an EHLO will follow that up with a standard HELO, on the same connection)

-the remote server supports ESMTP, but does not support the STARTTLS extension. 

Nearly every MTA on the web nowadays supports TLS (via STARTTLS). Your ISP's mail server should support it if it's something that's been updated in, oh, the past 8 years? TLS support first crept into the mainstream right around 2001 or 2002, with nearly everyone, including commercial vendors, supporting it by about 2005. The exception of course being qmail without patches, using solely 100% DJB code, but most people run qmail with patches - inclusive of those for TLS support.

----------

## methodtwo

Thank you very much. This is the friendliest forum I've ever used. It's great to see gurus who don't dismiss n00bs.

One last question: I take it you have to alter master.cf accordingly, in order for postfix to use dovecot SASL? Or is just altering main.cf enough for postfix to use dovecot SASL?

regards

----------

## cach0rr0

 *methodtwo wrote:*   

> Thank you very much. This is the friendliest forum I've ever used. It's great to see gurus who don't dismiss n00bs.

 

very happy to help. no, seriously, I'm always glad when someone actually asks something I actually know how to answer! 

 *methodtwo wrote:*   

> I take it you have to alter master.cf accordingly, in order for postfix to use dovecot SASL? Or is just altering main.cf enough for postfix to use dovecot SASL?
> 
> regards

 

nope, just main.cf, and realistically within main.cf you only need to set permit_sasl_authenticated within smtpd_recipient_restrictions

the smtpd_recipient_restrictions settings are parsed top to bottom, so you probably want your more "selective" permit rules towards the top, with a final "reject_unauth_destination" rule. 

The other main.cf settings relating to sasl are tweaks for the most part. 

Once you set up main.cf to use SASL, postfix will, when a user tries to auth, pass the request off to be authenticated however you've configured in /etc/sasl2/smtpd.conf 

If you set /etc/sasl2/smtpd.conf to use the 'saslauthd' method, then you'll also need to set up /etc/conf.d/saslauthd, and make sure saslauthd is running (e.g. start it up, and add it to the default runlevel)

In your case the SASL backend you're using is Dovecot's SASL - I must admit that's entirely foreign territory for me. I've used the following:

-using saslauthd, and telling it to validate auth credentials against local unix users

-backending sasl to a mysql database that contains a list of usernames and passwords

-backending sasl to its own little storage database, where you manually add users via the saslpasswd command. 

Once postfix is attempting sasl at all, you're finished with main.cf, and the rest is configuring /etc/sasl2/smtpd.conf and optionally /etc/conf.d/saslauthd

If in doubt, this postconf page is a treasure trove of information for what is a very very configurable MTA. I used it a fair bit when I wrote this (which is overkill for most users - dovecot is perfect for smallish simple installations). 

get stuck? post back, we'll get 'er answered.

----------

## methodtwo

Thanks once again mr/mrs/ms UNIX guru. From What i can remember when ever i've typed:

```
AUTH LOGIN
```

I don't think i got the correct response. Do you have to disable TLS when testing if SASL works?

I'll post back when i've run the test properly

Thanks again for all your authoritative responses

----------

## cach0rr0

 *methodtwo wrote:*   

> Thanks once again mr/mrs/ms UNIX guru. From What i can remember when ever i've typed:
> 
> ```
> AUTH LOGIN
> ```
> ...

 

Always pay attention to the banners postfix gives back to you. You should be looking for the "AUTH" banners after you issue your "EHLO"

 *methodtwo wrote:*   

> 
> 
> Do you have to disable TLS when testing if SASL works?
> 
> 

 

Nope, shouldn't need to - in fact, if you set smtpd_tls_auth_only = yes, auth will ONLY work if you connect via TLS

If you get to the point where you issue the EHLO, issue AUTH LOGIN, and then get back a 334 VXNlcm5hbWU6 response, auth is all sorted. 

If you're not getting that, post a snippet of how you're running the test. Your main.cf (anonymized is fine) would be helpful in such a case as well.

----------

## methodtwo

It's all working fine. Thank you very much for all the information you've given me. I think that i just tested it wrong before. I did, however get lots of potentially revealing information when testing with openssl s_client, i got sent the server cert and cipher etc. Is this normal and just the public key cert? And under SSL-Session, there was some text after the title master-key: ??

I can get the exact same response for AUTH LOGIN as you stated in your bit about testing SASL with openssl

Situation normal?

Also i'm only using self-signed certs, for postfix and dovecot. Do you think that is sufficient, for the purposes of a non-business, small, home network?

Do i have to be my own CA for other friends that might want to use my MTA? Or can i just give them certs signed by my private key? Is there any difference, effectively or otherwise between these two low security options?

Thanks once again for all the useful info

----------

## cach0rr0

 *methodtwo wrote:*   

> It's all working fine. Thank you very much for all the information you've given me. I think that i just tested it wrong before. I did, however get lots of potentially revealing information when testing with openssl s_client, i got sent the server cert and cipher etc. Is this normal and just the public key cert? And under SSL-Session, there was some text after the title master-key: ??
> 
> I can get the exact same response for AUTH LOGIN as you stated in your bit about testing SASL with openssl
> 
> Situation normal?
> ...

 

That all sounds fairly normal, yes. 

 *methodtwo wrote:*   

> 
> 
> Also i'm only using self-signed certs, for postfix and dovecot. Do you think that is sufficient, for the purposes of a non-business, small, home network?
> 
> 

 

I know people in large companies (even some government bodies, believe it or not) that use self-signed certs for SMTP/IMAP. It's actually fairly *uncommon* to use a cert signed by a so-called "trusted" CA for this purpose. Maybe it should be common for the uber paranoid, but it isn't. 

Some companies will use it on the SMTP side for compliance regulations, but this is exceedingly rare, as most MTA's you send to don't do any sort of validation of the certificate other than at most making sure it isn't expired, or non-matching. 

Self-signed cert should not be an issue at all. 

 *methodtwo wrote:*   

> 
> 
> Do i have to be my own CA for other friends that might want to use my MTA? Or can i just give them certs signed by my private key? Is there any difference, effectively or otherwise between these two low security options?
> 
> 

 

You literally don't need to do anything, nor issue them with anything. When their MTA connects to you, Postfix will automatically ship it a public key used for encrypting the traffic, the same as would automagically happen when you view an HTTPS website. 

On the IMAP side, their mail client will probably give them a prompt that says "hey, this is a self-signed cert, would you like to accept it? do you want to permanently trust it?" and that's the end of it.

----------

## methodtwo

Thank you ever so much for all your help and advice.

----------

