Best way to run Postfix on a single server for multiple domains

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Best way to run Postfix on a single server for multiple domains

Nitin N
Dear friends,

I have been using Postfix for sometime now for a single domain and it has been running smoothly with Dovecot. I use milters for Spamassasin, Clamav, Dkim, Dmarc & SPF. Postgrey has also been configured (although I think it could be removed in the long run). I have Postscreen enabled. TLS support has  been enabled with self-signed certificates.

Now, I have to migrate to a new server that is running FreeBSD 11. I need to support 4 domains on this single server with each domain having its own Trusted CA certified SSL digital certificate.

I can think of three ways to accomplish this and I am looking for some guidance based on your knowledge/experience with Postfix.

Method 1]

Use virtual domains on a single Postfix instance and override master.cf to take care of the individual SSL certificate for each domain using a separate IP in each case. Based on my research, I believe this could get complicated with Postscreen and other milters enabled. So I am not too keen on going this path. Correct me if I am wrong...

Method 2]

Use postmulti and create a separate instance for each domain. In this case, I am not sure how complex it might get if I want to create further instances for each domain to handle outgoing, incoming and null-client scenarios.

Method 3]

Use FreeBSD jails for each domain and a common jail for all the spam/virus protection services and use a proxy + NAT on the main host. This could also help me use postmulti in each jail in case I need to have multiple instances based on functions.

So based on your experience/expertise, which method would you recommend? Further, do you think I can stop using Postgrey as I also have Postscreen enabled?

I look forward to your responses.

Warm regards,

Nitin


Reply | Threaded
Open this post in threaded view
|

Re: Best way to run Postfix on a single server for multiple domains

/dev/rob0
On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote:

> Now, I have to migrate to a new server that is running FreeBSD 11.
> I need to support 4 domains on this single server with each domain
> having its own Trusted CA certified SSL digital certificate.
>
> I can think of three ways to accomplish this and I am looking for
> some guidance based on your knowledge/experience with Postfix.
>
> Method 1]
>
> Use virtual domains on a single Postfix instance and override
> master.cf to take care of the individual SSL certificate for each
> domain using a separate IP in each case. Based on my research, I
> believe this could get complicated with Postscreen and other
> milters enabled. So I am not too keen on going this path. Correct
> me if I am wrong...

Postscreen (which, BTW, is *not* a milter) and submission do not play
well together.  If you must accept submission on port 25, do so with
a distinct IP address which isn't published as MX for any of your
domains, and only accept authenticated users there.

If there's only one IP address and you cannot fix the problem of mail
users submitting mail on port 25, you're probably going to have to
disable postscreen.

Certificates only matter on submission, and there only if your user
base is large and beyond your control, such as at an ISP or
university.  Small-timers can just tell their users, "this is the TLS
certificate we're using, accept it."

> Method 2]
>
> Use postmulti and create a separate instance for each domain. In
> this case, I am not sure how complex it might get if I want to
> create further instances for each domain to handle outgoing,
> incoming and null-client scenarios.

Why would you want to do this?  If you're seeking Perfect Headers,
why?  Users mostly can't read nor understand headers.

> Method 3]
>
> Use FreeBSD jails for each domain and a common jail for all the
> spam/virus protection services and use a proxy + NAT on the main
> host. This could also help me use postmulti in each jail in case I
> need to have multiple instances based on functions.
>
> So based on your experience/expertise, which method would you
> recommend?

Method 4: use a single IP address for mail, tell users what name it
is (no reason why that name has to be "in their domain"), tell them
what certificate they need to accept in their MUAs.  Offer and accept
AUTH only on port 587; accept mail exchange only on port 25.

Your question and stated 3 methods indicate you don't understand much
about the place of TLS in SMTP.  Yes, a user sending mail through
your server needs to check (and to trust) your certificate, but
remote MTAs will usually not ask for it and do not care.

> Further, do you think I can stop using Postgrey as I also have
> Postscreen enabled?

With after-220 tests enabled, postscreen will easily block anything
postgrey might have blocked.  Also, greylisting, ISTM, is mostly
defeated by spammers' current methods.  It's typical for zombies to
go through their lists more than once.

> I look forward to your responses.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Best way to run Postfix on a single server for multiple domains

Nitin N
Dear Rob (I hope that is your name),

Thank you for your views/suggestion. My replies are inline tagged with my name, as in [Nitin:]


On Sat, Feb 11, 2017 at 8:53 PM, /dev/rob0 <[hidden email]> wrote:
On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote:
> Now, I have to migrate to a new server that is running FreeBSD 11.
> I need to support 4 domains on this single server with each domain
> having its own Trusted CA certified SSL digital certificate.
>
> I can think of three ways to accomplish this and I am looking for
> some guidance based on your knowledge/experience with Postfix.
>
> Method 1]
>
> Use virtual domains on a single Postfix instance and override
> master.cf to take care of the individual SSL certificate for each
> domain using a separate IP in each case. Based on my research, I
> believe this could get complicated with Postscreen and other
> milters enabled. So I am not too keen on going this path. Correct
> me if I am wrong...

Postscreen (which, BTW, is *not* a milter) and submission do not play
well together.  If you must accept submission on port 25, do so with
a distinct IP address which isn't published as MX for any of your
domains, and only accept authenticated users there.

If there's only one IP address and you cannot fix the problem of mail
users submitting mail on port 25, you're probably going to have to
disable postscreen.

Certificates only matter on submission, and there only if your user
base is large and beyond your control, such as at an ISP or
university.  Small-timers can just tell their users, "this is the TLS
certificate we're using, accept it."
 
[Nitin:]
 
Yes I do understand Postscreen is not a milter. Method 4 what you suggested below is more or less what my current configuration looks like i.e. my Method 1.
 

> Method 2]
>
> Use postmulti and create a separate instance for each domain. In
> this case, I am not sure how complex it might get if I want to
> create further instances for each domain to handle outgoing,
> incoming and null-client scenarios.

Why would you want to do this?  If you're seeking Perfect Headers,
why?  Users mostly can't read nor understand headers.

[Nitin:] 
One reason why we would like to have Perfect Headers is that one of the domains is a B2C platform where many users can register. We want to reduce all possibilities (as much as we can) of our first email to these users from getting marked as Spam. So, we believe having a CA Trusted certificate might just add some more credibility in this scenario. Honestly, I am not sure if we are being paranoid here since you mention below that MTAs don't really verify if the certificate used by another MTA is in fact Trusted or not.
  

> Method 3]
>
> Use FreeBSD jails for each domain and a common jail for all the
> spam/virus protection services and use a proxy + NAT on the main
> host. This could also help me use postmulti in each jail in case I
> need to have multiple instances based on functions.
>
> So based on your experience/expertise, which method would you
> recommend?


[Nitin:] 

Seems like not many have tried Method 3]. I think it might be a good path to take from a scalability/security point of view, although Jails do add some additional overhead from a maintenance perspective.
 
Method 4: use a single IP address for mail, tell users what name it
is (no reason why that name has to be "in their domain"), tell them
what certificate they need to accept in their MUAs.  Offer and accept
AUTH only on port 587; accept mail exchange only on port 25.

Your question and stated 3 methods indicate you don't understand much
about the place of TLS in SMTP.  Yes, a user sending mail through
your server needs to check (and to trust) your certificate, but
remote MTAs will usually not ask for it and do not care.

> Further, do you think I can stop using Postgrey as I also have
> Postscreen enabled?

With after-220 tests enabled, postscreen will easily block anything
postgrey might have blocked.  Also, greylisting, ISTM, is mostly
defeated by spammers' current methods.  It's typical for zombies to
go through their lists more than once.


[Nitin:] 

Thanks, so that means it bye-bye Postgrey, thanks to Postscreen :) 
 
> I look forward to your responses.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Reply | Threaded
Open this post in threaded view
|

Re: Best way to run Postfix on a single server for multiple domains

/dev/rob0
On Mon, Feb 13, 2017 at 12:20:45PM +0530, Nitin N wrote:
> Dear Rob (I hope that is your name),

That works, but I also answer to "hey you" and various epithets (you
can even google up a few from this very list. ;) )

> On Sat, Feb 11, 2017 at 8:53 PM, /dev/rob0 <[hidden email]> wrote:
> > On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote:

> > > Method 2]
> > >
> > > Use postmulti and create a separate instance for each domain.
> > > In this case, I am not sure how complex it might get if I want
> > > to create further instances for each domain to handle outgoing,
> > > incoming and null-client scenarios.
> >
> > Why would you want to do this?  If you're seeking Perfect
> > Headers, why?  Users mostly can't read nor understand headers.
>
> [Nitin:]
> One reason why we would like to have Perfect Headers is that one
> of the domains is a B2C platform where many users can register. We
> want to reduce all possibilities (as much as we can) of our first
> email to these users from getting marked as Spam. So, we believe
> having a CA Trusted certificate might just add some more
> credibility in this scenario.

It probably won't help.

Deliverability is a frequent concern for small sites, and there is no
single clear answer (nor group of answers) that will guarantee Inbox
access.  Thank the spammers, sigh.

The main steps are:

  1. FCrDNS: your PTR value is $myhostname, which in turn resolves to
     your IP address.  If you don't control the PTR you're sunk.
  2. IP Reputation (more on that to follow)
  3. Clean non-spammy practices (likewise)

IP reputation depends mostly on clean, non-spammy practices, but it
could also be linked to issues partly beyond your control, such as
your hosting ISP's reputation for abuse.  I say "partly" because you
always have the option to move to better-regarded hosting.

You can possibly improve your own reputation by signing up for
DNSWL.org (and possibly other whitelisting services.)  I use DNSWL
myself with the postscreen_dnsbl_whitelist_threshold feature, and it
is very useful.

I doubt any major providers use DNSWL directly, but I bet they check
their spam blocking against it.

"Clean" means, of course, that you must not be the source of UBE, nor
should you forward any UBE from your system to others.  "Spammy
practices" ... well, there are a lot of those, but they mostly boil
down to attempts to evade blacklisting.  If you're consistently
sending from a single IP address (or netblock if you're big enough,
but I don't think you'd be asking here if you were that big), with
static forward and reverse DNS entries, you're not looking like a
blacklist evader.

Another spammy practice which might look tempting is to send
"reminders" about registration emails.  You should only send ONE
single verification email, because before address verification you
have no way to know that it was a valid address.

> Honestly, I am not sure if we are being paranoid here since you
> mention below that MTAs don't really verify if the certificate used
> by another MTA is in fact Trusted or not.

Right.  And I said "probably won't help" above because it's possible
that some providers might do occasional checks of certificates.  But
it certainly won't matter that "example.net" hosts handle mail from
[hidden email].

> > > Method 3]
> > >
> > > Use FreeBSD jails for each domain and a common jail for all the
> > > spam/virus protection services and use a proxy + NAT on the
> > > main host. This could also help me use postmulti in each jail
> > > in case I need to have multiple instances based on functions.
> > >
> > > So based on your experience/expertise, which method would you
> > > recommend?
>
> Seems like not many have tried Method 3]. I think it might be a
> good path to take from a scalability/security point of view,
> although Jails do add some additional overhead from a maintenance
> perspective.

It seems like a lot of fuss for no actual benefit.  You get the warm
fuzzies when you examine your Received: headers, but that's not
getting you out of spam folders.

> > > Further, do you think I can stop using Postgrey as I also have
> > > Postscreen enabled?
> >
> > With after-220 tests enabled, postscreen will easily block
> > anything postgrey might have blocked.  Also, greylisting, ISTM,
> > is mostly defeated by spammers' current methods.  It's typical
> > for zombies to go through their lists more than once.
>
> Thanks, so that means it bye-bye Postgrey, thanks to Postscreen :)

Yes, and I can recommend my own postscreen config, which you can
find at:

http://rob0.nodns4.us/postscreen.html

Good luck.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Best way to run Postfix on a single server for multiple domains

Viktor Dukhovni

> On Feb 13, 2017, at 10:30 AM, /dev/rob0 <[hidden email]> wrote:
>
>> [Nitin:]
>> One reason why we would like to have Perfect Headers is that one
>> of the domains is a B2C platform where many users can register. We
>> want to reduce all possibilities (as much as we can) of our first
>> email to these users from getting marked as Spam. So, we believe
>> having a CA Trusted certificate might just add some more
>> credibility in this scenario.

It should perhaps be pointed out that certificates have a negligible
(likely negative) impact on (outbound) deliverability because receiving
servers rarely request client certificates from sending systems, and
when they are requested, they are at best ignored.

Some receiving systems shoot themselves in the foot and abort TLS
handshakes with client-certificates they don't like for various silly
reasons.  The mail is then often delivered in the clear instead.  The
solution to that problem is to follow the advice in the Postfix docs
and to NOT configure any client certificates.

   http://www.postfix.org/postconf.5.html#smtp_tls_cert_file

   Do not configure client certificates unless you *must* present
   client TLS certificates to one or more servers. Client certificates
   are not usually needed, and can cause problems in configurations
   that work well without them. The recommended setting is to let the
   defaults stand:

      smtp_tls_cert_file =
      smtp_tls_key_file =
      smtp_tls_dcert_file =
      smtp_tls_dkey_file =
      smtp_tls_eccert_file =
      smtp_tls_eckey_file =

We may at some point in the next year or two have a spec for
DANE client TLSA records.  At that point, client certificates
may start to be used for reasons other than to impede email
delivery.  Broad use is at least a decade away...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Best way to run Postfix on a single server for multiple domains

Nitin N
Dear Viktor,

Thanks for pointing out. 

My config currently does not alter the defaults for the settings mentioned by you. 

Warm regards,

Nitin

On Mon, Feb 13, 2017 at 9:34 PM, Viktor Dukhovni <[hidden email]> wrote:

> On Feb 13, 2017, at 10:30 AM, /dev/rob0 <[hidden email]> wrote:
>
>> [Nitin:]
>> One reason why we would like to have Perfect Headers is that one
>> of the domains is a B2C platform where many users can register. We
>> want to reduce all possibilities (as much as we can) of our first
>> email to these users from getting marked as Spam. So, we believe
>> having a CA Trusted certificate might just add some more
>> credibility in this scenario.

It should perhaps be pointed out that certificates have a negligible
(likely negative) impact on (outbound) deliverability because receiving
servers rarely request client certificates from sending systems, and
when they are requested, they are at best ignored.

Some receiving systems shoot themselves in the foot and abort TLS
handshakes with client-certificates they don't like for various silly
reasons.  The mail is then often delivered in the clear instead.  The
solution to that problem is to follow the advice in the Postfix docs
and to NOT configure any client certificates.

   http://www.postfix.org/postconf.5.html#smtp_tls_cert_file

   Do not configure client certificates unless you *must* present
   client TLS certificates to one or more servers. Client certificates
   are not usually needed, and can cause problems in configurations
   that work well without them. The recommended setting is to let the
   defaults stand:

      smtp_tls_cert_file =
      smtp_tls_key_file =
      smtp_tls_dcert_file =
      smtp_tls_dkey_file =
      smtp_tls_eccert_file =
      smtp_tls_eckey_file =

We may at some point in the next year or two have a spec for
DANE client TLSA records.  At that point, client certificates
may start to be used for reasons other than to impede email
delivery.  Broad use is at least a decade away...

--
        Viktor.


Reply | Threaded
Open this post in threaded view
|

Re: Best way to run Postfix on a single server for multiple domains

Nitin N
In reply to this post by /dev/rob0
Dear Rob,

Thank you for all your words of wisdom and for sharing your postscreen recommendations.

I also checked out your Youtube video talk on postscreen.  

It was good to see you in person :)

Warm regards,

Nitin

Ps: My earlier reply to you bounced back from the list as I had the word 'config' instead of 'recommendations' on in my first sentence :)

On Mon, Feb 13, 2017 at 9:00 PM, /dev/rob0 <[hidden email]> wrote:
On Mon, Feb 13, 2017 at 12:20:45PM +0530, Nitin N wrote:
> Dear Rob (I hope that is your name),

That works, but I also answer to "hey you" and various epithets (you
can even google up a few from this very list. ;) )

> On Sat, Feb 11, 2017 at 8:53 PM, /dev/rob0 <[hidden email]> wrote:
> > On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote:

> > > Method 2]
> > >
> > > Use postmulti and create a separate instance for each domain.
> > > In this case, I am not sure how complex it might get if I want
> > > to create further instances for each domain to handle outgoing,
> > > incoming and null-client scenarios.
> >
> > Why would you want to do this?  If you're seeking Perfect
> > Headers, why?  Users mostly can't read nor understand headers.
>
> [Nitin:]
> One reason why we would like to have Perfect Headers is that one
> of the domains is a B2C platform where many users can register. We
> want to reduce all possibilities (as much as we can) of our first
> email to these users from getting marked as Spam. So, we believe
> having a CA Trusted certificate might just add some more
> credibility in this scenario.

It probably won't help.

Deliverability is a frequent concern for small sites, and there is no
single clear answer (nor group of answers) that will guarantee Inbox
access.  Thank the spammers, sigh.

The main steps are:

  1. FCrDNS: your PTR value is $myhostname, which in turn resolves to
     your IP address.  If you don't control the PTR you're sunk.
  2. IP Reputation (more on that to follow)
  3. Clean non-spammy practices (likewise)

IP reputation depends mostly on clean, non-spammy practices, but it
could also be linked to issues partly beyond your control, such as
your hosting ISP's reputation for abuse.  I say "partly" because you
always have the option to move to better-regarded hosting.

You can possibly improve your own reputation by signing up for
DNSWL.org (and possibly other whitelisting services.)  I use DNSWL
myself with the postscreen_dnsbl_whitelist_threshold feature, and it
is very useful.

I doubt any major providers use DNSWL directly, but I bet they check
their spam blocking against it.

"Clean" means, of course, that you must not be the source of UBE, nor
should you forward any UBE from your system to others.  "Spammy
practices" ... well, there are a lot of those, but they mostly boil
down to attempts to evade blacklisting.  If you're consistently
sending from a single IP address (or netblock if you're big enough,
but I don't think you'd be asking here if you were that big), with
static forward and reverse DNS entries, you're not looking like a
blacklist evader.

Another spammy practice which might look tempting is to send
"reminders" about registration emails.  You should only send ONE
single verification email, because before address verification you
have no way to know that it was a valid address.

> Honestly, I am not sure if we are being paranoid here since you
> mention below that MTAs don't really verify if the certificate used
> by another MTA is in fact Trusted or not.

Right.  And I said "probably won't help" above because it's possible
that some providers might do occasional checks of certificates.  But
it certainly won't matter that "example.net" hosts handle mail from
[hidden email].

> > > Method 3]
> > >
> > > Use FreeBSD jails for each domain and a common jail for all the
> > > spam/virus protection services and use a proxy + NAT on the
> > > main host. This could also help me use postmulti in each jail
> > > in case I need to have multiple instances based on functions.
> > >
> > > So based on your experience/expertise, which method would you
> > > recommend?
>
> Seems like not many have tried Method 3]. I think it might be a
> good path to take from a scalability/security point of view,
> although Jails do add some additional overhead from a maintenance
> perspective.

It seems like a lot of fuss for no actual benefit.  You get the warm
fuzzies when you examine your Received: headers, but that's not
getting you out of spam folders.

> > > Further, do you think I can stop using Postgrey as I also have
> > > Postscreen enabled?
> >
> > With after-220 tests enabled, postscreen will easily block
> > anything postgrey might have blocked.  Also, greylisting, ISTM,
> > is mostly defeated by spammers' current methods.  It's typical
> > for zombies to go through their lists more than once.
>
> Thanks, so that means it bye-bye Postgrey, thanks to Postscreen :)

Yes, and I can recommend my own postscreen config, which you can
find at:

http://rob0.nodns4.us/postscreen.html

Good luck.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: