# Allow authenticated relay for Postfix

## dageyra

Hello all, I have a development machine that gets moved around a lot on different ISPs (Comcast/ATT/etc), all of which have issues with sending mail.  Though they often offer a relay option, ATT (the current provider) is more of an issue due to the From email addresses having to be verified.  I would like to stop dealing with all of this and use a mail server that is stationed at one location.

This server is in a collocation facility and currently just processes mail like any other mail server would for certain organizations.  I would like to use this mail server in place of the ISP relay options mentioned above, but obviously this type of relay is turned off in Postfix as it only sends on behalf of known entities.  I don't want to mess with the way the Postfix is currently running, that is fine, but I would like to add the functionality that, for authenticated users, the mail server will act as a relay server in the same way Comcast/ATT would act above.  I know how to setup my development server to use a relay, but I am not clear on how to setup the colo mail server to act as a relay option for the development server.

So I am looking for guidance on how to do this.  All of the stuff I'm finding online is about setting up Postfix to work with an outbound relay server already available, not setting up a Postfix server to act as a relay.  The colo mail server currently authenticates users that send/receive mail through PAM.  I believe TLS & SASL are options to use, I have used SASL in the past for Comcast.

Are there any resources/tutorials that do what I want, or maybe some quick suggested configuration changes that would help me get this up and running quickly?  I am not a Postfix expert by any means, so any help you can offer will be greatly appreciated.

My ideal setup would be able to set the relayhost in my development machine to be mail.server.com:587 (or some port, 25 is not an option), and then use SASL to define a username/password already in place on the mail.server.com through basic PAM authentication.  I then need the mail.server.com to listen and act as a relay on 587 (it currently does not, only port 25) and relay any email that is authenticated.  I know this probably very simple, Postfix is very flexible, but again, it's just not my area of expertise.  Thanks again, everyone.

----------

## cach0rr0

I'm lost in all the words, and admittedly it's largely due to my own laziness. 

Are you trying to configure Postfix to authenticate to an upstream SMTP server? 

OR

Are you trying to set it up so that your Postfix system requires SMTP authentication, but delivers its mail directly to the destination without going through another relay?

The latter I can help with off the top of my head. The former I'd have to look.

For the latter, enabling sasl auth goes like so:

under the smtp_recipient_restrictions, add permit_sasl+authenticated, ABOVE any 'reject' settings e.g.:

```

smtpd_recipient_restrictions =

        permit_mynetworks,

        permit_sasl_authenticated,

        reject_unauth_destination

```

You will also want these options somewhere in main.cf

```

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_local_domain = yourdomain.com

smtpd_sasl_authenticated_header = yes

broken_sasl_auth_clients = yes

smtpd_tls_auth_only = yes

```

For me, I allow plaintext auth, BUT, I only allow it if someone has connected via TLS. In fact I don't even advertise AUTH capability unless it's via TLS - that's controlled with the 'smtpd_tls_auth_only' setting. 

From there it's just setting up the actual SASL pieces - two files involved potentially, /etc/conf.d/saslauthd and /etc/sasl2/smtpd.conf

----------

## cach0rr0

Actually, I'll stop being lazy and try to digest this

 *Quote:*   

> 
> 
> My ideal setup would be able to set the relayhost in my development machine to be mail.server.com:587 (or some port, 25 is not an option), 
> 
> 

 

So, you have a postfix installation on your dev machine, that you want to relay upstream to mail.server.com? 

 *Quote:*   

> 
> 
> and then use SASL to define a username/password already in place on the mail.server.com through basic PAM authentication. I then need the mail.server.com to listen and act as a relay on 587 (it currently does not, only port 25) and relay any email that is authenticated. 
> 
> 

 

So this seems to suggest you want the following setup

mail client=>devmachine.domain.com:25 => mail.domain.com:465 (with devmachine authenticating to mail.domain.com via SASL, backended to PAM) => internet 

Is that correct? Or are you happy to take the mail portion off of devmachine.domain.com and just route everything directly from mail client through mail.domain.com ?

----------

## dageyra

 *cach0rr0 wrote:*   

> I'm lost in all the words, and admittedly it's largely due to my own laziness. 
> 
> Are you trying to configure Postfix to authenticate to an upstream SMTP server? 
> 
> OR
> ...

 

Sorry about that, I have a tendency to ramble.  The answer is both, there are two servers, but I only need help with one part (setting up Postfix to act as the upstream SMTP relay).  My development server needs to authenticate to another SMTP relay server due to ISP blocking port 25, however this I know how to do (have done it with Comcast).  I want to do it with another server we have that never changes and is in collocated (unlike having to change from Comcast to ATT to Time Warner when the development server moves).  The colo server also runs Postfix, and it is with this part I need help.  So, I want the collocated mail.server.com to act as a relay and deliver mail, via authentication, that comes from my dev server.  I also want to ensure that the current functionality of mail.server.com, which is just to send/receive mail for local users, does not change.  It is this part I am not clear on, but I have found this page:

http://www.linuxquestions.org/questions/linux-server-73/postfix-only-accept-relay-mail-from-authenticated-users-673730/

This says I just need to change smtpd_recipient_restrictions to include "permit_sasl_authenticated", and then it will work.  The end goal is that I can use the development server to send email, on port 587 (the ISP is blocking 25 which causes the whole mess) through mail.server.com, and I will use SASL authentication.  I found this page that tells me how to enable 587: http://rackerhacker.com/2007/07/04/enable-submission-port-587-in-postfix/

One thing that is not clear from the page I found is whether or not the credentials I pass via SASL will be authenticated on mail.server.com via PAM (which is how Postfix currently authenticates from a user logging in from an email client).  I have a username and password for shell access on that server and a corresponding email account, so I want to use that authentication.

Does that make more sense?

----------

## dageyra

 *cach0rr0 wrote:*   

> Actually, I'll stop being lazy and try to digest this
> 
>  *Quote:*   
> 
> My ideal setup would be able to set the relayhost in my development machine to be mail.server.com:587 (or some port, 25 is not an option), 
> ...

 

Yeh, you got it, but I want devmachine to continue doing it's mail thing as I use it to test various Gentoo issues, which would include configuring/updating Postfix.  There are some users that only have mail account on devmachine, so I want them to still be able to send/receive mail, which as you see now I believe would actually be routing through mail.domain.com.  One thing that I want to be sure that is that people can't just route mail through mail.domain.com as they feel like, I only want to allow authenticated relay.  It's kind of a scary notion that I could be opening up the mail.domain.com to anyone in the world routing their spam through us.

----------

## cach0rr0

 *dageyra wrote:*   

> 
> 
> One thing that is not clear from the page I found is whether or not the credentials I pass via SASL will be authenticated on mail.server.com via PAM (which is how Postfix currently authenticates from a user logging in from an email client).  I have a username and password for shell access on that server and a corresponding email account, so I want to use that authentication.
> 
> 

 

"the credentials i pass via SASL"

are you passing these to the dev server (via your mail client), and you want those transmitted upstream? 

Getting the upstream server to listen on an alternate port, and accept sasl auth, isn't particularly painful. I just need to know if that's *all* we need to worry about getting set up, and if you have all of the other pieces covered.

Because off the top of my head, if you're looking to pass auth credentials to the dev server's smtp server, and then have the dev server do a "passthrough" of sorts, where it takes whatever auth credentials you give it, and passes it upstream to mail.domain.com, that's a bit more complex

----------

## dageyra

So my initial thought that just changing smtpd_recipient_restrictions would work is not the case, as I get this: 

Mar 12 23:05:14 dev postfix/smtp[32448]: 90BD162161: to=<dev@example.com>, relay=mail.domain.com:587, delay=0.76, delays=0.02/0.01/0.66/0.06, dsn=5.7.1, status=bounced (host mail.domain.com said: 554 5.7.1 <dev@example.com>: Relay access denied (in reply to RCPT TO command))

So I will wait for you to offer some advice, thanks again for the help.

----------

## dageyra

 *cach0rr0 wrote:*   

>  *dageyra wrote:*   
> 
> One thing that is not clear from the page I found is whether or not the credentials I pass via SASL will be authenticated on mail.server.com via PAM (which is how Postfix currently authenticates from a user logging in from an email client).  I have a username and password for shell access on that server and a corresponding email account, so I want to use that authentication.
> 
>  
> ...

 

No, those credentials won't be transmitted upstream.  The way it was done with Comcast is that, on the dev machine, I set relayhost = smtp.comcast.net and some other Postfix config, then I have a sasl db file that contains the Comcast username.  The dev Postfix ensures that users sending mail are authenticated and then sends the mail to Comcast using the configuration.  I want to replace Comcast in this scenario using my username/password on mail.domain.com.  So, to do that, I just need mail.domain.com to act as a relay in the same manner Comcast did and authenticate me, then send the email on behalf of the dev server.

----------

## cach0rr0

 *dageyra wrote:*   

> So my initial thought that just changing smtpd_recipient_restrictions would work is not the case, as I get this: 
> 
> Mar 12 23:05:14 dev postfix/smtp[32448]: 90BD162161: to=<dev@example.com>, relay=mail.domain.com:587, delay=0.76, delays=0.02/0.01/0.66/0.06, dsn=5.7.1, status=bounced (host mail.domain.com said: 554 5.7.1 <dev@example.com>: Relay access denied (in reply to RCPT TO command))
> 
> So I will wait for you to offer some advice, thanks again for the help.

 

so a few things:

-did you add in those other sasl auth pieces to main.cf? (I edited my first reply to add some extra info, but i was a bit slow in doing so)

-i assume you did the 'postfix reload' after adding that setting? 

-what settings, if any, do you have in /etc/sasl2/smtpd.conf and/or /etc/conf.d/saslauthd ?

----------

## cach0rr0

 *dageyra wrote:*   

> 
> 
> No, those credentials won't be transmitted upstream.  The way it was done with Comcast is that, on the dev machine, I set relayhost = smtp.comcast.net and some other Postfix config, then I have a sasl db file that contains the Comcast username.  The dev Postfix ensures that users sending mail are authenticated and then sends the mail to Comcast using the configuration.  I want to replace Comcast in this scenario using my username/password on mail.domain.com.  So, to do that, I just need mail.domain.com to act as a relay in the same manner Comcast did and authenticate me, then send the email on behalf of the dev server.

 

right, ok, so that's one thing (I use comcast as well, and had to do that same dance too for a long while!), smtp.comcast.net will accept totally unauthenticated relay, from any domain, to any domain, if the connecting IP address is from one of its customers. Your mail system at the colo will not. So, basically, before devmachine wasnt having to provide any auth data to the relayhost at comcast. With the relayhost set to your colo system, it will. 

That's the wrinkle. We *do* need to get your dev machine's postfix passing authentication to the upstream postfix install (the one at the colo)

----------

## dageyra

 *cach0rr0 wrote:*   

>  *dageyra wrote:*   So my initial thought that just changing smtpd_recipient_restrictions would work is not the case, as I get this: 
> 
> Mar 12 23:05:14 dev postfix/smtp[32448]: 90BD162161: to=<dev@example.com>, relay=mail.domain.com:587, delay=0.76, delays=0.02/0.01/0.66/0.06, dsn=5.7.1, status=bounced (host mail.domain.com said: 554 5.7.1 <dev@example.com>: Relay access denied (in reply to RCPT TO command))
> 
> So I will wait for you to offer some advice, thanks again for the help. 
> ...

 

No, I had not added those (did not notice them), but I will go back and ensure they are there.  I did the postfix restart (I never think to do reload).  Below I have the settings you requested (I assumed you wanted the mail server I want to act as a relay, not the dev; please let me know if you want the dev information and I will provide it).  I will respond once I incorporate the other settings you suggested, maybe that will take care of it.

```

$ cat /etc/sasl2/smtpd.conf

# $Header: /var/cvsroot/gentoo-x86/mail-mta/postfix/files/smtp.sasl,v 1.2 2004/07/18 03:26:56 dragonheart Exp $

pwcheck_method: saslauthd

mech_list: plain login

```

```

$ cat /etc/conf.d/saslauthd

# $Header: /var/cvsroot/gentoo-x86/dev-libs/cyrus-sasl/files/saslauthd-2.1.21.conf,v 1.2 2007/04/07 13:03:55 chtekk Exp $

# Config file for /etc/init.d/saslauthd

# Initial (empty) options.

SASLAUTHD_OPTS=""

# Specify the authentications mechanism.

# **NOTE** For a list see: saslauthd -v

# Since 2.1.19, add "-r" to options for old behavior,

# ie. reassemble user and realm to user@realm form.

#SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -a pam -r"

SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -a pam"

# Specify the hostname for remote IMAP server.

# **NOTE** Only needed if rimap auth mechanism is used.

#SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -O localhost"

# Specify the number of worker processes to create.

#SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -n 5"

# Enable credential cache, set cache size and timeout.

# **NOTE** Size is measured in kilobytes.

#          Timeout is measured in seconds.

#SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -c -s 128 -t 30"

```

----------

## cach0rr0

just to expand on that a bit, have a look at this quickie telnet example:

```

# telnet smtp.comcast.net 25

Trying 76.96.30.117...

Connected to smtp.comcast.net.

Escape character is '^]'.

220 omta15.emeryville.ca.mail.comcast.net comcast ESMTP server ready

EHLO vpn.whitehathouston.com

250-omta15.emeryville.ca.mail.comcast.net hello [75.148.243.89], pleased to meet you

250-HELP

250-AUTH LOGIN PLAIN

250-SIZE 15728640

250-ENHANCEDSTATUSCODES

250-8BITMIME

250-STARTTLS

250 OK

MAIL FROM:<forged@yahoo.com>

250 2.1.0 <forged@yahoo.com> sender ok

RCPT TO:<meat@whitehathouston.com>

250 2.1.5 <meat@whitehathouston.com> recipient ok

```

----------

## cach0rr0

 *dageyra wrote:*   

> 
> 
> ```
> 
> $ cat /etc/sasl2/smtpd.conf
> ...

 

ok, those two are fine. The first tells postfix to dump auth requests off to saslauthd (which must be running, of course), and accept plain/login auth methods. 

The second tells saslauthd to backend to pam (it can backend to tons of stuff - pam, ldap, flat file, you name it)

With those two set as they are, saslauthd running, and main.cf configured with the previous suggestions, you should have the upstream server set to accept SASL auth, backended against pam

However, here's the trick: what will the upstream server receive authentication from? The dev machine receives its authentication from the mail client. And now you have the dev machine connected to the colo machine. The colo machine also requires authentication yeah (unlike smtp.comcast.net)? So where is it getting it from? 

We need to find a way to passthrough auth from the dev machine to the colo machine - for that, I'll need to exercise my Google Fu.

----------

## dageyra

I have all of the requested settings in place now (the only one I was confused about was smtpd_sasl_local_domain, not sure what this should be and it was just blank originally).  The dev server is still telling me relay denied.  I can provide the full main.cf on the relay server, but I would want to get rid of the comments (I keep full comments as I'm not a Postfix expert and I find them useful when needing to understand configuration changes).  I don't know if you know how to pull out the text without comments, I've done it before but cannot recall.

The response on the dev server is the same as what I posted before (I did restart Postfix on the relay server).  Here is the relevant part I changed/added (for the domain, I just put in what would be considered the main domain, though this is not the same as FQDN for the mail server if that is what should go there, I need to change it):

```

# tls stuff

smtp_use_tls = yes

smtpd_use_tls = yes

#smtp_tls_note_starttls_offer = yes

smtpd_tls_key_file = /etc/ssl/postfix/server.pem

smtpd_tls_cert_file = /etc/ssl/postfix/server.pem

smtpd_tls_CAfile = /etc/ssl/postfix/server.pem

#smtpd_tls_loglevel = 2

#smtpd_tls_received_header = yes

#smtpd_tls_session_cache_timeout = 3600s

#tls_random_source = dev:/dev/urandom

# sasl stuff

smtpd_sasl_auth_enable = yes

smtpd_sasl_local_domain = domain.com

broken_sasl_auth_clients = yes

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10030

smtpd_sasl_security_options = noanonymous

smtpd_sasl_authenticated_header = yes

smtpd_tls_auth_only = yes

# this section is used when postfix sends email to a remote MX domain

#smtp_sasl_password_maps = hash:/usr/local/postfix/etc/sasl_passwd

# smtp_sasl_password_maps = hash:/etc/passwd

# smtp_sasl_auth_enable = yes

#transport_maps = hash:/etc/postfix/transport

```

Last edited by dageyra on Sun Mar 13, 2011 5:20 am; edited 2 times in total

----------

## dageyra

 *cach0rr0 wrote:*   

> 
> 
> ...
> 
> However, here's the trick: what will the upstream server receive authentication from? The dev machine receives its authentication from the mail client. And now you have the dev machine connected to the colo machine. The colo machine also requires authentication yeah (unlike smtp.comcast.net)? So where is it getting it from? 
> ...

 

The authentication on the relay machine is handled in the saslpassword file.  I know that Comcast does not require authentication, but Google/ATT does, so the relevant config for that is:

```

# Collocated server settings

relayhost =  mail.domain.com:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/saslpass.domain

# Comcast settings

#relayhost =  smtp.comcast.net:587

#smtp_sasl_auth_enable = yes

#smtp_sasl_password_maps = hash:/etc/postfix/saslpass.comcast

#smtp_sasl_security_options = noanonymous

# ATT settings

#relayhost = [smtp.att.yahoo.com]:587

#smtp_sasl_auth_enable = yes

#smtp_tls_security_level = may

#smtp_sasl_password_maps = hash:/etc/postfix/saslpass.att

#smtp_sasl_mechanism_filter = plain, login

#smtp_sasl_security_options = noanonymous

# Google settings

#relayhost = smtp.gmail.com:587

#smtp_sasl_password_maps = hash:/etc/postfix/saslpass.gmail

```

You can see in the various settings for different providers, there is a saslpass file (I created this, most of the time it's just /etc/postfix/saslpass, but since the dev machine moves a lot, I found it easier to use different files).  This file is a Postfix database file which contains the username/password that is sent from the dev machine to the relay server.  It's a standard [server name]:port username:password format, but for ATT and Gmail, it's email address and not password.  The text version of the file is mapped into a db file via postmap (similar to virtual maps).  I have this setup and ready for the relay server:

```

# less saslpass.domain

[mail.domain.com]:587 username:password

```

This username/password is the same credentials I use to send/receive email on the collocated mail server, and they work fine through Postfix.  The only question I don't know is if when connecting to the relay, does Postfix use the same authentication methodology (PAM) as when connecting regularly for mail actually sent from the relay server (i.e., not through a relay, default behavior).

----------

## cach0rr0

 *dageyra wrote:*   

> I have all of the requested settings in place now (the only one I was confused about was smtpd_sasl_local_domain, not sure what this should be and it was just blank originally).  The dev server is still telling me relay denied. 

 

This log snippet would seem to indicate that it is the upstream server, not the dev server, that is denying the relay attempt:

```

Mar 12 23:05:14 dev postfix/smtp[32448]: 90BD162161: to=<dev@example.com>, relay=mail.domain.com:587, delay=0.76, delays=0.02/0.01/0.66/0.06, dsn=5.7.1, status=bounced (host mail.domain.com said: 554 5.7.1 <dev@example.com>: Relay access denied (in reply to RCPT TO command))

```

And this is something I would actually expect; the dev server has received authentication, but the colo server has not. So the colo server (mail.domain.com) is rejecting the message. 

 *dageyra wrote:*   

> 
> 
> ```
> 
> ########this section is for people authenticating to your dev server. 
> ...

 

Added some comments to the above code snippets explaining things.

----------

## cach0rr0

 *dageyra wrote:*   

> 
> 
> The authentication on the relay machine is handled in the saslpassword file.  I know that Comcast does not require authentication, but Google/ATT does, so the relevant config for that is:
> 
> ```
> ...

 

 *dageyra wrote:*   

> 
> 
> ```
> 
> # less saslpass.domain
> ...

 

ah, right, so you DO already have the dev=>upstream authentication set up (or well, it's commented out there, but it's set up)

i wasn't sure if you'd already worked out how to get that piece done - seems you do

 *dageyra wrote:*   

> 
> 
> This username/password is the same credentials I use to send/receive email on the collocated mail server, and they work fine through Postfix.  The only question I don't know is if when connecting to the relay, does Postfix use the same authentication methodology (PAM) as when connecting regularly for mail actually sent from the relay server (i.e., not through a relay, default behavior).

 

connecting through which relay? 

And postfix will not send any auth of any sort unless you explicitly tell it to do so for one domain or another (this, is default behaviour)

The auth mech it uses when acting as an smtp *client* will depend on what the upstream host advertises, how the upstream host is configured, etc

The auth mech it uses when acting as an smtp *server* are determined by /etc/sasl2/smtpd.conf, and if you tell it to use saslauthd in smtpd.conf, how /etc/conf.d/saslauthd is set up

----------

## cach0rr0

NB: this thread is one giant race condition, with you answering my questions *before* i finish asking them  :Laughing: 

----------

## dageyra

 *cach0rr0 wrote:*   

> 
> 
> ah, right, so you DO already have the dev=>upstream authentication set up (or well, it's commented out there, but it's set up)
> 
> i wasn't sure if you'd already worked out how to get that piece done - seems you do
> ...

 

Yeh, the SASL authentication I've copied from other working relays (specifically Comcast, but I think ATT was working too, just required "verified" email address, screw that) is in place and updated.  The lines for connecting to the relay server I am trying to setup are not commented and should be in use on the dev server.  I've re-run postmap and restarted everything just to be sure, still getting the same "Relay access denied" error.

On the relay note, I just meant that I am paranoid about opening up the mail.domain.com to relay and want to be sure everything requires authentication (i.e., I understand open relays are bad and the colo ISP would not be happy).

So, I think the main issue right now is that the dev server is receiving "Relay access denied".

I'm going to post the updated/latest main.cf from each server in case you see something I've missed:

dev server:

```

user@dev /etc/postfix # grep ^[^#] ./main.cf

queue_directory = /var/spool/postfix

command_directory = /usr/sbin

daemon_directory = /usr/lib/postfix

data_directory = /var/lib/postfix

mail_owner = postfix

smtp_bind_address=192.168.1.25

myhostname = dev.domain.com

mydomain = domain.com

myorigin = $mydomain

inet_interfaces = all

mydestination = $myhostname, localhost.$myhostname, $mydomain

local_recipient_maps = unix:passwd.byname $alias_maps

unknown_local_recipient_reject_code = 550

virtual_alias_maps = hash:/etc/postfix/virtual_maps

alias_maps = hash:/etc/mail/aliases

alias_database = hash:/etc/mail/aliases

mailman_destination_recipient_limit = 1

recipient_delimiter = +

home_mailbox = Maildir/

mailbox_command = /usr/bin/procmail

smtpd_banner = $myhostname ESMTP

debug_peer_level = 2

debugger_command =

         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin

         ddd $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/sbin/sendmail

newaliases_path = /usr/bin/newaliases

mailq_path = /usr/bin/mailq

setgid_group = postdrop

html_directory = /usr/share/doc/postfix-2.5.5/html

smtp_use_tls = yes

smtpd_use_tls = yes

smtp_tls_note_starttls_offer = yes

smtpd_tls_key_file = /etc/ssl/postfix/server.pem

smtpd_tls_cert_file = /etc/ssl/postfix/server.pem

smtpd_tls_CAfile = /etc/ssl/postfix/server.pem

tls_random_source = dev:/dev/urandom

smtp_tls_scert_verifydepth = 5

smtpd_tls_ask_ccert = yes

smtpd_tls_req_ccert =no

smtp_tls_enforce_peername = no

smtpd_sasl_auth_enable = yes

broken_sasl_auth_clients = no

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

smtpd_sasl_authenticated_header = yes

smptd_sasl_security_options = noanonymous

relayhost =  mail.domain.com:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/saslpass.domain

virtual_alias_domains = <<domains removed to protect the innocent>>

sample_directory = /etc/postfix

message_size_limit = 20480000

```

collocated server (want to act as relay:

```

user@mail /etc/postfix $ grep ^[^#] ./main.cf

queue_directory = /var/spool/postfix

command_directory = /usr/sbin

daemon_directory = /usr/lib/postfix

mail_owner = postfix

smtp_bind_address=<<IP removed to protect the innocent>>

myhostname = mail.domain.com

mydomain = domain.com

myorigin = $mydomain

inet_interfaces = all

mydestination = $myhostname, localhost.$myhostname, $mydomain

local_recipient_maps = unix:passwd.byname $alias_maps

unknown_local_recipient_reject_code = 550

alias_maps = hash:/etc/mail/aliases, hash:/usr/local/mailman/data/aliases

virtual_alias_maps = hash:/etc/postfix/virtual_maps, hash:/usr/local/mailman/data/virtual-mailman

alias_database = hash:/etc/mail/aliases, hash:/usr/local/mailman/data/aliases

mailman_destination_recipient_limit = 1

recipient_delimiter = +

home_mailbox = Maildir/

mailbox_command = /usr/bin/procmail

smtpd_banner = $myhostname ESMTP

debug_peer_level = 2

debugger_command =

         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin

         xxgdb $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/sbin/sendmail

newaliases_path = /usr/bin/newaliases

mailq_path = /usr/bin/mailq

setgid_group = postdrop

readme_directory = no

smtp_use_tls = yes

smtpd_use_tls = yes

smtpd_tls_key_file = /etc/ssl/postfix/server.pem

smtpd_tls_cert_file = /etc/ssl/postfix/server.pem

smtpd_tls_CAfile = /etc/ssl/postfix/server.pem

smtpd_sasl_auth_enable = yes

smtpd_sasl_local_domain = domain.com

broken_sasl_auth_clients = yes

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10030

smtpd_sasl_security_options = noanonymous

smtpd_sasl_authenticated_header = yes

smtpd_tls_auth_only = yes

virtual_alias_domains = <<domains removed to protect the innocent>>

message_size_limit = 20480000

```

Perhaps there is some way to test the relay through a telnet connection?  If you can provide an example, I can try it out myself with my credentials to see what happens, that way we know if it's the relay or dev server.  Also, I do notice that some entries are repeated, the result of trying different things.  I will clean it up when finished unless that is the problem, but I thought the earlier config would be overwritten by end-of-file config.  Also, I'd like to find out why greylisting is harmful as we've had tremendous success with it over the years, some users seeing their spam reduced by a magnitude of 10.Last edited by dageyra on Sun Mar 13, 2011 5:20 am; edited 1 time in total

----------

## dageyra

 *cach0rr0 wrote:*   

> NB: this thread is one giant race condition, with you answering my questions *before* i finish asking them 

 

I noticed that too, so I waited for the follow-up reply before I posted my latest reply.  I think we're both on the same page now, I posted the two main.cf so that we can try to determine what is causing the relay access denied error, either the dev or relay server.  I am glad to know this is going to be possible.

----------

## dageyra

Just discovered something else, I cannot use this line:

```

smtpd_tls_auth_only = yes

```

We have users that do not use TLS, kind of a long story, but basically it creates problems in certain scenarios, so there is plain auth going on.  I ran some tests and indeed the mail won't send for regular users (who would not be using the relay) and I can't have that just to have a dev machine relaying email.  I hope that won't be a big problem?  With or without the line, I still get "Relay access denied" on the dev machine.

----------

## dageyra

Ok, once the require TLS directive was gone, I was able to telnet to 587 and use plain login and send email.  Doesn't this mean the relay is working?  It worked fine from my own email and to another email.  This seems like the colo mail server will accept relay for authenticated users (via PAM).  So, that means there is something wrong with dev, right?  I think in general the TLS is an issue so I'm trying to remove it from the situation altogether and see if it works that way, then we can incorporate security.  What changes are needed to the dev main.cf to allow straight through authentication, similar to what was done in the telnet session?

----------

## cach0rr0

 *dageyra wrote:*   

> Ok, once the require TLS directive was gone, I was able to telnet to 587 and use plain login and send email.  Doesn't this mean the relay is working?

 

so it would seem. If auth+sending to the colo machine works via telnet, and you can be certain the dev postfix server is sending those same credentials when it delivers to the colo machine, I'd say the colo machine is squared away. 

 *dageyra wrote:*   

> 
> 
> So, that means there is something wrong with dev, right?  I think in general the TLS is an issue so I'm trying to remove it from the situation altogether and see if it works that way, then we can incorporate security.  What changes are needed to the dev main.cf to allow straight through authentication, similar to what was done in the telnet session?

 

Should just be the same smtpd_* settings from I think my second post, with the exception of the smtpd_tls_auth_only parameter. 

```

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_local_domain = whitehathouston.com #I don't think this is needed if you use PAM - http://www.postfix.org/postconf.5.html#smtpd_sasl_local_domain

smtpd_sasl_authenticated_header = yes

broken_sasl_auth_clients = yes

```

and then this under smtpd_recipient_restrictions

```

        permit_sasl_authenticated,

```

----------

## dageyra

 *cach0rr0 wrote:*   

>  *dageyra wrote:*   Ok, once the require TLS directive was gone, I was able to telnet to 587 and use plain login and send email.  Doesn't this mean the relay is working? 
> 
> so it would seem. If auth+sending to the colo machine works via telnet, and you can be certain the dev postfix server is sending those same credentials when it delivers to the colo machine, I'd say the colo machine is squared away. 
> 
>  *dageyra wrote:*   
> ...

 

Yeh, as far as I can tell, we have all that setup, do you have any suggestions on what tests we can run?  Or maybe logs to peak at to find out what is going wrong?  I'm not familiar with SASL to find out whether the password is being passed appropriately.

----------

## dageyra

Here are some log entries I noticed on the relay server that seem to be tied to the connection from the dev server event:

```

Mar 13 03:02:12 mail postfix/smtpd[17145]: sql_select option missing

Mar 13 03:02:12 mail postfix/smtpd[17145]: auxpropfunc error no mechanism available

Mar 13 03:02:12 mail postfix/smtpd[17145]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

Mar 13 03:02:12 mail postfix/smtpd[17145]: auxpropfunc error invalid parameter supplied

Mar 13 03:02:12 mail postfix/smtpd[17145]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb

```

----------

## dageyra

Incredible, you probably won't believe this, but I figured it out.

```
relayhost = mail.domain.com:587
```

I looked at this line and noticed that in the saslpassword file I had [mail.domain.com]:587.  I have no idea what the brackets are for, but by including them in the main.cf, everything worked!

The new line looked like this:

```
relayhost = [mail.domain.com]:587
```

I will see about re-adding TLS for security reasons, but do you have other thoughts on the use of grey listing?

----------

## cach0rr0

 *dageyra wrote:*   

>  I have no idea what the brackets are for, but by including them in the main.cf, everything worked!

 

Ah right. So those are basically:

mail.domain.com:587 == do an MX lookup for 'mail.domain.com', and send to whichever MX is returned

[mail.domain.com]:587 == just send to mail.domain.com on port 587 dammit! Screw the MX lookup, just send it, don't question me, I am the configurator. 

(brackets disable MX lookups)

 *dageyra wrote:*   

> do you have other thoughts on the use of grey listing?

 

Just in general? None that are positive. That's fuel for a rant unfortunately. Some implementations are better than others (policyd v1 has a fairly intelligent configuration, should you choose to make one), but nowadays I'd say they block off as much (if not more) legitimate mail as they do spam, and introduce delays unnecessarily just for the sake of introducing delays. 

Nearly every piece of spam nowadays is sent via spambot, and nearly every one I've analyzed (which, is a large proportion of what I do in my professional career)has retry code, easily defeating greylisting. 

Talked my old company out of instituting greylisting in their software (we were a vendor), fast forward a few years later, at a new company whose product had greylisting by default - one of the first things I did was rip that out. For whatever that's worth. 

You're not really defeating the bots. You're delaying mail until they've waited long enough to have an authenticated triplet (and with most implementations, thankfully, you can cache this positive result and not greylist that host for $timeperiod). There's just so little gain. And then you consider, even though there shouldn't be, there are still huge chunks of, for example, web mailer implementations out there that don't use their system's sendmail() function, and instead try to crudely code their own SMTP stack. Crudely doing so without any concept of a queue, so any message that isn't accepted on the first try is just junked into the bit bucket. Also not at all uncommon for a greylisting implementation to blacklist a host after X number of failed attempts in too rapid succession - only wait,  you have no way of advertising your acceptable retry time to another host, so they may keep retrying every 120 seconds, when your threshold is 300 seconds. 

Coupling the risks with the marginal to nil benefits, I can't recommend greylisting for anyone. 

Worried about spam, looking for a freebie method? RBL's aren't as crap as some paranoid people might like to say. Some people just shit a brick over them, shit a brick over the idea of letting a third party dictate your filtering, but fact of the matter is, they work, and they work well. Especially so, if you're being selective with the RBL's you choose - look for a sane listing policy, a sane delisting policy, and your risks of missing legitimate mail are exceedingly low. 

I'm confident enough in the RBL's I've chosen for my system, I don't even let them connect, don't wait on the RCPT command to issue the 550:

```

smtpd_delay_reject = no

smtpd_client_restrictions =

        permit_mynetworks

        reject_rbl_client ix.dnsbl.manitu.net

        reject_rbl_client cbl.abuseat.org

        reject_rbl_client b.barracudacentral.org

        reject_rbl_client new.spam.dnsbl.sorbs.net

```

Is that all I use? No. When I was still using exclusively my own filtering, I also had amavisd-new in the picture, plugged into spamassassin and clamav. Didn't use the SA rules, just wrote my own, copied over some of the stuff from work (required a slight formatting change, but it wasn't too difficult). Of course, now I use my company's filtering, so I've dropped amavis/clam/SA to save myself a bit of memory. But when I *was* running that setup, my catch rate was very, very acceptable.

----------

