Re: Configuration Syntax

[Doug Hardie]

> On 7 July 2017, at 08:44, Noel Jones  wrote:
> 
> On 7/7/2017 12:37 AM, Doug Hardie wrote:
>> 
>>> On 6 July 2017, at 12:40, Doug Hardie  wrote:
>>> 
 
 On 6 July 2017, at 12:06, Noel Jones  wrote:
 
 main.cf doesn't allow spaces in the options.  The supported syntax
 is to either use commas "," rather than spaces; enclose the option
 in braces "{ ... }"; or the preferred method of defining a macro in
 main.cf and reference it in master.cf.  See the master.cf man page.
 
 # main.cf
 my_smtpd_restrictions =
 check_policy_service inet:127.0.0.1:10040
 reject_invalid_hostname,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,
 reject_unauth_pipelining,
 permit_mynetworks,
 reject_unauth_destination,
 reject_rbl_client bl.spamcop.net
 permit
 
 # master.cf
 smtpd  pass  -   -   n   -   -   smtpd
 -o smtpd_recipient_restrictions=$my_smtpd_restrictions
>>> 
>>> 
>>> Thanks.  That makes sense now.
>> 
>> Well, I thought I understood it, but now am not so sure so here is what I 
>> have ready to try.  I still am a bit confused in the macro in main.cf some 
>> of the lines have a comma at the end and others do not.  When is the comma 
>> needed?
> 
> main.cf treats comma, space, tab, and newline, all as whitespace,
> and they can be used interchangeably. Insert commas as desired for
> readability. See the main.cf manpage.
> 
>> 
>> main.cf
>> #   Incoming restrictions and Implement postfwd
>> incoming_smtpd_restrictions =
>>check_policy_service inet:127.0.0.1:10040
>>reject_invalid_hostname,
>>reject_non_fqdn_sender,
>>reject_non_fqdn_recipient,
>>reject_unknown_sender_domain,
>>reject_unknown_recipient_domain,
>>reject_unauth_pipelining,
>>permit_mynetworks,
>>check_recipient_access hash:/usr/local/etc/postfix/tempfail
>>reject_unauth_destination,
>>reject_rbl_client bl.spamcop.net
>>permit
>> 
>> Virtual_alias_maps file:
>> bc97...@lafn.orgdoug
>> ...
>> 
>> tempfail file:
>> bc97...@lafn.org450 4.2.1 This mailbox is unavailable today
>> 
>> 
>> master.cf:
>> smtpd  pass  -   -   n   -   -   smtpd
>> submission inet n   -   n   -   -   smtpd
>>-o smtpd_recipient_restrictions=permit_mynetworks
>> 
> 
> Your submission options must have a reject at the end.  Most folks
> use permit_sasl_authenticated instead of permit_mynetworks on
> submission, but use whatever is correct for your server.
>  -o smtpd_recipient_restrictions=permit_mynetworks,reject
> 
> Note master.cf syntax difference; no spaces around the comma.
> 
> 
>  -- Noel Jones

Thank you.  That was a clear explanation.

Re: postscreen with postgrey - can they cause a double reject?

[techlist06]

Thank you for the expert input.  I will heed your advise.

Scott





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/postscreen-with-postgrey-can-they-cause-a-double-reject-tp91176p91183.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: postscreen delay inprovement - multple IP addresses

[techlist06]

Thanks guys, I understand now.  Much appreciated.




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/postscreen-delay-inprovement-multple-IP-addresses-tp91174p91182.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: postscreen with postgrey - can they cause a double reject?

[/dev/rob0]

On Fri, Jul 07, 2017 at 05:18:49PM -0500, techlist06 wrote:
> - postscreen with postgrey - can they cause a double reject?

Reject, no; deferral, of course yes.

> I searched for answers regarding using both postscreen and 
> greylisting.  I saw some differing opinions.  But I did not
> see this point covered.

My opinion is that postscreen is a much better greylisting-like 
implementation.  I do not recommend other greylisting now (and this 
opinion dates back many years.)

> Assuming a clients first connection to me to deliver and
> Assuming that postscreen is configured for deep protocol tests,
> and the connection passes all tests.
> 
> I understand postscreen will temporary whitelist the IP but the 
> client must reconnect in order to deliver.

Yes, but see:

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

Most legitimate senders are listed in the DNSWL.org whitelist.
Clients in that list (without offsetting DNSBL listings, which have 
been very rare) bypass postscreen's delaying behavior.

> On that second connection, postscreen hands off to postfix
> due to the temporary whitelist.

Postscreen IS Postfix; it hands off to smtpd(8).

> If I have greylisting configured, as I have done it in the
> past in main.cf:
> 
>   smtpd_recipient_restrictions 
> ...
> check_policy_service unix:postgrey/socket
> permit
> 
> Won't this second connection get temp rejected by my normal 
> greylisting a second time?  The regular greylisting won't know 
> about the postscreen's recent pass.  So won't the client would
> have to connect for a 3rd time to deliver?
> 
> That would seem to me to be an argument against using both, or

Correct.

> at least using both with postscreen's deep protocol tests
> enabled.
> 
> I'd be grateful to be straightened out if I have it wrong.  

Just stick with postscreen's deep protocol tests.  Greylisting won't 
block anything that got through postscreen's delay.  All pain, no 
gain, with greylisting behind postscreen.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Require TLS on internet-facing servers?

[/dev/rob0]

On Fri, Jul 07, 2017 at 10:40:47AM -0700,
  robg...@nospammail.net wrote:
> I am starting to setup a Postfix server for our office.
> 
> I'm looking at TLS policy.
> 
> Reading old posts on the Postfix mailing lists there's lots of 
> comments that REQUIRING tls should never be done on an public 
> internet-facing server.
> 
> But those comments are from 5-7 yrs ago.
> 
> Is that still the case?
> 
> On a friend's server we just checked 3 months of logs.  IIUC 
> there's been no non-TLS connections at all in that time:

I use a warn_if_reject reject_plaintext_session restriction at 
end-of-DATA, so I have some numbers which might not be relevant to 
anyone else, but there are two main classes of plaintext mail 
arriving at my site:

1. Legitimate (solicited & confirmed) marketing mail
2. Free software project mailing lists (not this one)

Your numbers (and classes) would vary if you tinker with TLS settings 
such that you won't accept "weak" ciphers.  (Is a weak cipher weaker 
than plaintext?)  My cipher settings are all Postfix defaults.

> Second, if there are actually no non-encrypted connections, is
> it time finally to simply require it?

I won't.  It's not like TLS in SMTP is going to make a huge 
difference for privacy.  I suppose big mail services like gmail are 
scanning mail content for their own use, and quite likely are 
allowing national governments to do the same.

TLS addresses a single, relatively minor security concern, of 
protection of data in transit.  Yes, that is a good thing, but 
remember: you're also trusting the administrators of the other 
endpoint.

If you really want to be a privacy advocate, start using GnuPG for 
end-to-end email encryption.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: postscreen delay inprovement - multple IP addresses

[Wietse Venema]

techlist06:
> I'm working on converting to using postscreen.  Studying the details.  I
> have a question from the docs related to the delays due to the effective
> greylisting caused by "Tests after the 220 SMTP server greeting".  I believe
> my server would qualify as a small site receiving mail for just a few
> hundred users.
> 
> Snippet from the Howto:
> " The following measures may help to avoid email delays:   Small sites:
> Configure postscreen(8) to listen on multiple IP addresses, published in DNS
> as different IP addresses for the same MX hostname or for different MX
> hostnames. This avoids mail delivery delays with clients that reconnect
> immediately from the same IP address.

Note, this recommendation applies to clients that reconnect from
the same IP address.

> Can someone help me understand why this helps?

The postscreen temporary whitelist is by client IP address.

> If I add an IP to the server and configure it as a second instance
> of the MX hostname, how does that help with a server that may
> reconnect from a different IP?

Note, the above recommendation applies to clients that reconnect
from above recommendation does not apply.

> I though tthat if it
> reconnected immediately from the same IP, that would be a good thing.  Or
> maybe I misunderstood "immediately".  I took it to mean immediately after
> getting a 4xx response and drop.  I assume this doesn't do anything to help
> with servers like Google that will connect from a different server?

Note, the abive recommendation applies to clients that reconnect
from the same IP address. If still applies when different servers
share the same external (NAT) IP address.

Wietse

Re: Require TLS on internet-facing servers?

[Viktor Dukhovni]

On Fri, Jul 07, 2017 at 03:04:11PM -0700, li...@lazygranch.com wrote:

> Would there be some way to redirect unencrypted email to some other server.
> Gmail for instance.  I would then force encryption on my personal server.

SMTP does not have "redirects".  SMTP security policy is up to the client:

http://www.postfix.org/TLS_README.html#client_tls_limits

Just enable STARTTLS on the server, and let the clients do the rest.
There's little to be gained on enforcing TLS on inbound SMTP servers
(``MX hosts'').  By all means enforce TLS for submission, and enable
opportunistic TLS or opportunistic DANE TLS on your outbound SMTP
transport.

Rumour has it that the US army is finally aiming to deploy STARTTLS
circa July 2018:


https://motherboard.vice.com/en_us/article/bjxjxv/the-pentagon-says-it-will-start-encrypting-soldiers-emails-next-year

The fraction of mail using TLS reported by Gmail has grown considerably
over the last few years, and is now hovering around 90% by volume.
Of course much of their traffic is to other large consumer email
providers that also support STARTTLS, and not to mailing lists or
other "niche" destinations that might not bother.

https://www.google.com/transparencyreport/saferemail/

-- 
Viktor.

postscreen with postgrey - can they cause a double reject?

[techlist06]

- postscreen with postgrey - can they cause a double reject?

I searched for answers regarding using both postscreen and greylisting.  I
saw some differing opinions.  But I did not see this point covered.

Assuming a clients first connection to me to deliver and
Assuming that postscreen is configured for deep protocol tests, and the
connection passes all tests.

I understand postscreen will temporary whitelist the IP but the client must
reconnect in order to deliver.  

On that second connection, postscreen hands off to postfix due to the
temporary whitelist.

If I have greylisting configured, as I have done it in the past in main.cf:

  smtpd_recipient_restrictions 
  ...
  check_policy_service unix:postgrey/socket
  permit

Won't this second connection get temp rejected by my normal greylisting a
second time?  The regular greylisting won't know about the postscreen's
recent pass.  So won't the client would have to connect for a 3rd time to
deliver?

That would seem to me to be an argument against using both, or at least
using both with postscreen's deep protocol tests enabled.

I'd be grateful to be straightened out if I have it wrong.  

Re: Require TLS on internet-facing servers?

[lists]

Would there be some way to redirect unencrypted email to some other server. 
Gmail for instance.  I would then force encryption on my personal server.

I'm down to one contact (as in a person I know) that isn't using encryption. I 
made two converts!  I haven't checked mailing lists for encryption. 



  Original Message  
From: Wietse Venema
Sent: Friday, July 7, 2017 11:32 AM
To: Postfix users
Reply To: Postfix users
Subject: Re: Require TLS on internet-facing servers?

Correction: my numbers were off because I used case-insensitive search.

robg...@nospammail.net:
> Hello,
> 
> I am starting to setup a Postfix server for our office.
> 
> I'm looking at TLS policy.
> 
> Reading old posts on the Postfix mailing lists there's lots of
> comments that REQUIRING tls should never be done on an public
> internet-facing server.
>
> But those comments are from 5-7 yrs ago.
>
> Is that still the case?

Your server, your rules...

> On a friend's server we just checked 3 months of logs. IIUC there's
> been no non-TLS connections at all in that time:
>
> grep -i "connection established" postfix*.log | wc -l
> 125217
>
> grep -i "connection established" postfix*.log | grep -v TLS | wc
> -l
> 0
>
> First, is that a legitimate way to check?

No, because "connection established" is logged only for TLS
connections. You'd also have to count the lines with "connect from"
which covers both TLS and non-TLS.

On my tiny server, only 43% of all inbound connections in June 2017
used TLS (a negligible portion of the "connection established" lines
were from tlsproxy).

And that is only for the 4.9% of connections that weren't blocked
by postscreen (25% of all unique clients).

If I were to block non-TLS email, I would miss a lot of email.

Wietse

postscreen delay inprovement - multple IP addresses

[techlist06]

I'm working on converting to using postscreen.  Studying the details.  I
have a question from the docs related to the delays due to the effective
greylisting caused by "Tests after the 220 SMTP server greeting".  I believe
my server would qualify as a small site receiving mail for just a few
hundred users.

Snippet from the Howto:
" The following measures may help to avoid email delays:   Small sites:
Configure postscreen(8) to listen on multiple IP addresses, published in DNS
as different IP addresses for the same MX hostname or for different MX
hostnames. This avoids mail delivery delays with clients that reconnect
immediately from the same IP address.

Can someone help me understand why this helps?  If I add an IP to the server
and configure it as a second instance of the MX hostname, how does that help
with a server that may reconnect from a different IP?  I though tthat if it
reconnected immediately from the same IP, that would be a good thing.  Or
maybe I misunderstood "immediately".  I took it to mean immediately after
getting a 4xx response and drop.  I assume this doesn't do anything to help
with servers like Google that will connect from a different server?

Anyway, I'd apprecaite it if someone could elaboate so I understand this
detail.

Thank you, Scott

Re: Require TLS on internet-facing servers?

[Wietse Venema]

Correction: my numbers were off because I used case-insensitive search.

robg...@nospammail.net:
> Hello,
> 
> I am starting to setup a Postfix server for our office.
> 
> I'm looking at TLS policy.
> 
> Reading old posts on the Postfix mailing lists there's lots of
> comments that REQUIRING tls should never be done on an public
> internet-facing server.
>
> But those comments are from 5-7 yrs ago.
>
> Is that still the case?

Your server, your rules...

> On a friend's server we just checked 3 months of logs.  IIUC there's
> been no non-TLS connections at all in that time:
>
> grep -i "connection established" postfix*.log | wc -l
> 125217
>
> grep -i "connection established" postfix*.log  | grep -v TLS | wc
> -l
>  0
>
> First, is that a legitimate way to check?

No, because "connection established" is logged only for TLS
connections.  You'd also have to count the lines with "connect from"
which covers both TLS and non-TLS.

On my tiny server, only 43% of all inbound connections in June 2017
used TLS (a negligible portion of the "connection established" lines
were from tlsproxy).

And that is only for the 4.9% of connections that weren't blocked
by postscreen (25% of all unique clients).

If I were to block non-TLS email, I would miss a lot of email.

Wietse

Require TLS on internet-facing servers?

[robgane]

Hello,

I am starting to setup a Postfix server for our office.

I'm looking at TLS policy.

Reading old posts on the Postfix mailing lists there's lots of comments that 
REQUIRING tls should never be done on an public internet-facing server.

But those comments are from 5-7 yrs ago.

Is that still the case?

On a friend's server we just checked 3 months of logs.  IIUC there's been no 
non-TLS connections at all in that time:

grep -i "connection established" postfix*.log | wc -l
125217

grep -i "connection established" postfix*.log  | grep -v TLS | wc -l  
 0

And that's with what I understand to be a 'may' policy.

First, is that a legitimate way to check?

Second, if there are actually no non-encrypted connections, is it time finally 
to simply require it?

Rob

Re: Configuration Syntax

[Noel Jones]

On 7/7/2017 12:37 AM, Doug Hardie wrote:
> 
>> On 6 July 2017, at 12:40, Doug Hardie  wrote:
>>
>>>
>>> On 6 July 2017, at 12:06, Noel Jones  wrote:
>>>
>>> main.cf doesn't allow spaces in the options.  The supported syntax
>>> is to either use commas "," rather than spaces; enclose the option
>>> in braces "{ ... }"; or the preferred method of defining a macro in
>>> main.cf and reference it in master.cf.  See the master.cf man page.
>>>
>>> # main.cf
>>> my_smtpd_restrictions =
>>>  check_policy_service inet:127.0.0.1:10040
>>>  reject_invalid_hostname,
>>>  reject_non_fqdn_sender,
>>>  reject_non_fqdn_recipient,
>>>  reject_unknown_sender_domain,
>>>  reject_unknown_recipient_domain,
>>>  reject_unauth_pipelining,
>>>  permit_mynetworks,
>>>  reject_unauth_destination,
>>>  reject_rbl_client bl.spamcop.net
>>>  permit
>>>
>>> # master.cf
>>> smtpd  pass  -   -   n   -   -   smtpd
>>> -o smtpd_recipient_restrictions=$my_smtpd_restrictions
>>
>>
>> Thanks.  That makes sense now.
> 
> Well, I thought I understood it, but now am not so sure so here is what I 
> have ready to try.  I still am a bit confused in the macro in main.cf some of 
> the lines have a comma at the end and others do not.  When is the comma 
> needed?

main.cf treats comma, space, tab, and newline, all as whitespace,
and they can be used interchangeably. Insert commas as desired for
readability. See the main.cf manpage.

> 
> main.cf
> #   Incoming restrictions and Implement postfwd
> incoming_smtpd_restrictions =
> check_policy_service inet:127.0.0.1:10040
> reject_invalid_hostname,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> reject_unauth_pipelining,
> permit_mynetworks,
> check_recipient_access hash:/usr/local/etc/postfix/tempfail
> reject_unauth_destination,
> reject_rbl_client bl.spamcop.net
> permit
> 
> Virtual_alias_maps file:
> bc97...@lafn.orgdoug
> ...
> 
> tempfail file:
> bc97...@lafn.org450 4.2.1 This mailbox is unavailable today
> 
> 
> master.cf:
> smtpd  pass  -   -   n   -   -   smtpd
> submission inet n   -   n   -   -   smtpd
> -o smtpd_recipient_restrictions=permit_mynetworks
> 

Your submission options must have a reject at the end.  Most folks
use permit_sasl_authenticated instead of permit_mynetworks on
submission, but use whatever is correct for your server.
  -o smtpd_recipient_restrictions=permit_mynetworks,reject

Note master.cf syntax difference; no spaces around the comma.


  -- Noel Jones