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

[Nitin N]

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  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  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
> send...@example.com.
>
> > > > 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 

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  wrote:

>
> > On Feb 13, 2017, at 10:30 AM, /dev/rob0  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.
>
>

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  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.

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  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 
send...@example.com.

> > > 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:

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  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:
>

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: