[no subject]

2015-12-04 Thread juodumas
Good day,

Why does postfix accept mail to 'RCPT TO: ' on submission
port, even when smtpd_recipient_restrictions are set to
permit_sasl_authenticated,reject? It's postfix-2.11.0 on Ubuntu
trusty. Excerpt from chat session and configs below.

$ openssl s_client -connect mail.my-domain.com:587 -starttls smtp -quiet
250 DSN
EHLO localhost
250-mail.my-domain.com
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: 
250 2.1.0 Ok
RCPT TO: 
554 5.7.1 : Recipient address rejected: Access denied
RCPT TO: 
250 2.1.5 Ok

$ postconf -n
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
default_database_type = cdb
disable_vrfy_command = yes
mailbox_size_limit = 0
message_size_limit = 104857600
mydestination = localhost.localdomain localhost
myhostname = mail.my-domain.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = mail.my-domain.com
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = swl.spamhaus.org*-5 
list.dnswl.org=127.0.[2..14].[2..3]*-5 zen.spamhaus.org*2 
bl.spameatingmonkey.net*2 bl.mailspike.net*2 bl.spamcop.net truncate.gbudb.net 
psbl.surriel.com rbl.megarbl.net
postscreen_dnsbl_threshold = 5
postscreen_dnsbl_whitelist_threshold = -1
postscreen_greet_action = enforce
receive_override_options = no_address_mappings
relay_domains =
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_restrictions = reject_unknown_reverse_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname warn_if_reject 
reject_unknown_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks 
reject_unknown_recipient_domain reject_non_fqdn_recipient 
reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/ssl/local/mail.my-domain.com.bundle.crt
smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
smtpd_tls_key_file = /etc/ssl/private/mail.my-domain.com.key
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
strict_rfc821_envelopes = yes
tls_ssl_options = NO_COMPRESSION
virtual_alias_maps = cdb:/etc/postfix/virtual
virtual_mailbox_domains = my-domain.com my-domain-2.com
virtual_transport = lmtp:unix:private/dovecot-lmtp

$ postconf -Mf
smtp   inet  n   -   -   -   1   postscreen
smtpd  pass  -   -   -   -   -   smtpd
dnsblogunix  -   -   -   -   0   dnsblog
submission inet  n   -   -   -   -   smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_mandatory_ciphers=high
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=
-o smtpd_recipient_restrictions=
-o 
smtpd_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
pickup unix  n   -   -   60  1   pickup
cleanupunix  n   -   -   -   0   cleanup
qmgr   unix  n   -   n   300 1   qmgr
tlsmgr unix  -   -   -   1000?   1   tlsmgr
rewriteunix  -   -   -   -   -   trivial-rewrite
bounce unix  -   -   -   -   0   bounce
defer  unix  -   -   -   -   0   bounce
trace  unix  -   -   -   -   0   bounce
verify unix  -   -   -   -   1   verify
flush  unix  n   -   -   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   -   -   -   smtp
relay  unix  -   -   -   -   -   smtp
showq  unix  n   -   -   -   -   showq
error  unix  -   -   -   -   -   error
retry  unix  -   -   -   -   -   error
discardunix  -   -   -   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   -   -   -   lmtp
anvil  unix  -   -   -   -   1   anvil
scache unix  -   -   -   -   1   scache
amavisfeed unix  -   - 

Why is recipient accepted on submission port?

2015-12-04 Thread juodumas


juodu...@gmail.com wrote:
> Good day,
> 
> Why does postfix accept mail to 'RCPT TO: ' on submission
> port, even when smtpd_recipient_restrictions are set to
> permit_sasl_authenticated,reject? It's postfix-2.11.0 on Ubuntu
> trusty. Excerpt from chat session and configs below.
> 
> $ openssl s_client -connect mail.my-domain.com:587 -starttls smtp -quiet
> 250 DSN
> EHLO localhost
> 250-mail.my-domain.com
> 250-PIPELINING
> 250-SIZE 104857600
> 250-ETRN
> 250-AUTH PLAIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> MAIL FROM: 
> 250 2.1.0 Ok
> RCPT TO: 
> 554 5.7.1 : Recipient address rejected: Access 
> denied
> RCPT TO: 
> 250 2.1.5 Ok
> 
> $ postconf -n
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> content_filter = amavisfeed:[127.0.0.1]:10024
> default_database_type = cdb
> disable_vrfy_command = yes
> mailbox_size_limit = 0
> message_size_limit = 104857600
> mydestination = localhost.localdomain localhost
> myhostname = mail.my-domain.com
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> myorigin = mail.my-domain.com
> postscreen_dnsbl_action = drop
> postscreen_dnsbl_sites = swl.spamhaus.org*-5 
> list.dnswl.org=127.0.[2..14].[2..3]*-5 zen.spamhaus.org*2 
> bl.spameatingmonkey.net*2 bl.mailspike.net*2 bl.spamcop.net 
> truncate.gbudb.net psbl.surriel.com rbl.megarbl.net
> postscreen_dnsbl_threshold = 5
> postscreen_dnsbl_whitelist_threshold = -1
> postscreen_greet_action = enforce
> receive_override_options = no_address_mappings
> relay_domains =
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtpd_client_restrictions = reject_unknown_reverse_client_hostname
> smtpd_data_restrictions = reject_unauth_pipelining
> smtpd_helo_required = yes
> smtpd_helo_restrictions = reject_invalid_helo_hostname warn_if_reject 
> reject_unknown_helo_hostname
> smtpd_recipient_restrictions = permit_mynetworks 
> reject_unknown_recipient_domain reject_non_fqdn_recipient 
> reject_unauth_destination
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
> reject_unauth_destination
> smtpd_sender_restrictions = reject_unknown_sender_domain
> smtpd_tls_cert_file = /etc/ssl/local/mail.my-domain.com.bundle.crt
> smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
> smtpd_tls_key_file = /etc/ssl/private/mail.my-domain.com.key
> smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
> smtpd_tls_protocols = !SSLv2 !SSLv3
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> strict_rfc821_envelopes = yes
> tls_ssl_options = NO_COMPRESSION
> virtual_alias_maps = cdb:/etc/postfix/virtual
> virtual_mailbox_domains = my-domain.com my-domain-2.com
> virtual_transport = lmtp:unix:private/dovecot-lmtp
> 
> $ postconf -Mf
> smtp   inet  n   -   -   -   1   postscreen
> smtpd  pass  -   -   -   -   -   smtpd
> dnsblogunix  -   -   -   -   0   dnsblog
> submission inet  n   -   -   -   -   smtpd
> -o syslog_name=postfix/submission
> -o smtpd_tls_security_level=encrypt
> -o smtpd_tls_mandatory_ciphers=high
> -o smtpd_sasl_auth_enable=yes
> -o smtpd_sasl_type=dovecot
> -o smtpd_sasl_path=private/auth
> -o smtpd_client_restrictions=
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_data_restrictions=
> -o smtpd_end_of_data_restrictions=
> -o smtpd_recipient_restrictions=
> -o 
> smtpd_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
> pickup unix  n   -   -   60  1   pickup
> cleanupunix  n   -   -   -   0   cleanup
> qmgr   unix  n   -   n   300 1   qmgr
> tlsmgr unix  -   -   -   1000?   1   tlsmgr
> rewriteunix  -   -   -   -   -   trivial-rewrite
> bounce unix  -   -   -   -   0   bounce
> defer  unix  -   -   -   -   0   bounce
> trace  unix  -   -   -   -   0   bounce
> verify unix  -   -   -   -   1   verify
> flush  unix  n   -   -   1000?   0   flush
> proxymap   unix  -   -   n   -   -   proxymap
> proxywrite unix  -   -   n   -   1   proxymap
> smtp   unix  -   -   -   -   -   smtp
> relay  unix  -   -   -   -   -   smtp
> showq  unix  n   -   -   -   -   showq
> error  unix  -   -   -   -   -   error
> retry  unix  -   -   -   -   -   error
> discardunix  -   -   -   -   -   discard
> local  unix  -   n   n   -   -   local
> virtualunix  -

I can't find the reason for this smtpd/opendmarc warning.

2015-12-04 Thread Robert Chalmers
I have opendmarc configured in postfix main.cf

###
# dkim & dmarc
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
non_smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
milter_default_action = accept


and the opendmarc.conf configured and as far as I can tell, all is well - 
except for this warning

postfix/smtpd[27575]: warning: connect to Milter service inet:127.0.0.1:8893: 
Connection refused




Robert Chalmers
rob...@chalmers.com .au  Quantum Radio: 
http://tinyurl.com/lwwddov
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. 2TB 
Storage made up of - 
Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower 
Bay





Re: I can't find the reason for this smtpd/opendmarc warning.

2015-12-04 Thread Danny Horne
My first thought is that is anything actually running on port 8893?

On 04/12/2015 10:19 am, Robert Chalmers wrote:
> I have opendmarc configured in postfix main.cf
>
> ###
> # dkim & dmarc
> smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
> non_smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
> milter_default_action = accept
> 
>
> and the opendmarc.conf configured and as far as I can tell, all is
> well - except for this warning
>
> postfix/smtpd[27575]: warning: connect to Milter service
> inet:127.0.0.1:8893: Connection refused
>
>
>
>
> Robert Chalmers
> rob...@chalmers.com .au  Quantum Radio:
> http://tinyurl.com/lwwddov
> Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan
> 10.11. 2TB Storage made up of - 
> Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024
> HN-M101MBB. Lower Bay
>
>
>
>
>
> 
> Avast logo   
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com 
>
>



signature.asc
Description: OpenPGP digital signature


Re: I can't find the reason for this smtpd/opendmarc warning.

2015-12-04 Thread Robert Chalmers
Sorry - went back to user, not list.

_opendmarc  29480   0.0  0.0  2464732660   ??  Ss   10:51am   0:00.02 
/usr/local/sbin/opendmarc -c /usr/local/etc/opendmarc/opendmarc.conf

Seems to be running …

also a simple 

telnet localhost 8893
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

.
Connection closed by foreign host.

Seems to be at least connecting



Robert Chalmers
rob...@chalmers.com .au  Quantum Radio: 
http://tinyurl.com/lwwddov 
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. 2TB 
Storage made up of - 
Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower 
Bay



> On 4 Dec 2015, at 10:38, Danny Horne  > wrote:
> 
> My first thought is that is anything actually running on port 8893?
> 
> On 04/12/2015 10:19 am, Robert Chalmers wrote:
>> I have opendmarc configured in postfix main.cf
>> 
>> ###
>> # dkim & dmarc
>> smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
>> non_smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
>> milter_default_action = accept
>> 
>> 
>> and the opendmarc.conf configured and as far as I can tell, all is well - 
>> except for this warning
>> 
>> postfix/smtpd[27575]: warning: connect to Milter service 
>> inet:127.0.0.1:8893: Connection refused
>> 
>> 
>> 
>> 
>> Robert Chalmers
>> rob...@chalmers.com .au  Quantum Radio: 
>> http://tinyurl.com/lwwddov 
>> Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. 
>> 2TB Storage made up of - 
>> Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. 
>> Lower Bay
>> 
>> 
>> 
>> 
>> 
>>     
>> This email has been checked for viruses by Avast antivirus software. 
>> www.avast.com 
> 



Re: Why is recipient accepted on submission port?

2015-12-04 Thread Wietse Venema
juodu...@gmail.com:
> > Why does postfix accept mail to 'RCPT TO: ' on submission
> > port, even when smtpd_recipient_restrictions are set to
> > permit_sasl_authenticated,reject? 

See RFC 5321, the document that defines SMTP.

Wietse


Re: Why is recipient accepted on submission port?

2015-12-04 Thread juodumas
Wietse Venema wrote:
> juodu...@gmail.com:
> > > Why does postfix accept mail to 'RCPT TO: ' on submission
> > > port, even when smtpd_recipient_restrictions are set to
> > > permit_sasl_authenticated,reject? 
> 
> See RFC 5321, the document that defines SMTP.
> 
>   Wietse
> 

Thanks for the reply.

I find it strange that postfix accepts , but rejects
 on this port (both variants are working on
25/smtp). I think it should be either all or none. In addition to
saying that the reserved mailbox name  MUST be accepted,
RFC 5321 also says that  MUST be supported:
   The requirement to accept mail for postmaster implies that RCPT
   commands that specify a mailbox for postmaster at any of the
   domains for which the SMTP server provides mail service, as well as
   the special case of "RCPT TO:" (with no domain
   specification), MUST be supported.

Is there a way to direct mail with  recipient to
amavis-external content_filter as opposed to amavis-auth, which I
intend to use for mail coming in through the submission service?

Also, Google is violating the RFC:
$ openssl s_client -connect smtp.gmail.com:587 -starttls smtp -quiet
250 SMTPUTF8
HELO localhost
250 smtp.gmail.com at your service
MAIL FROM: 
530-5.5.1 Authentication Required. Learn more at
530 5.5.1  https://support.google.com/mail/answer/14257 l7sm11474238wjx.14 - 
gsmtp
RCPT TO: 
530-5.5.1 Authentication Required. Learn more at
530 5.5.1  https://support.google.com/mail/answer/14257 l7sm11474238wjx.14 - 
gsmtp

-- 
juodumas


Found: .... the reason for this smtpd/opendmarc warning.

2015-12-04 Thread Robert Chalmers
this warning …
warning: connect to Milter service inet:127.0.0.1:8893: Connection refused


I started opendmarc as root, and the warning went away.

sudo /usr/local/sbin/opendmarc -v -c /usr/local/etc/opendmarc/opendmarc.conf

_opendmarc  29480   0.0  0.0  2482232820   ??  Ss   10:51am   0:00.04 
/usr/local/sbin/opendmarc -c /usr/local/etc/opendmarc/opendmarc.conf




Robert

Re: Why is recipient accepted on submission port?

2015-12-04 Thread Viktor Dukhovni
On Fri, Dec 04, 2015 at 02:20:53PM +0200, juodu...@gmail.com wrote:

> I find it strange that postfix accepts , but rejects
>  on this port (both variants are working on
> 25/smtp).

This is a work-around for "reject_non_fqdn_recipient" which applies
to all addresses except "postmaster".  Bottom-line "postmaster" is
exempt from restriction processing.  Explicit submission support
was added to Postfix long after the basic foundations were laid.

Yes, the exemption for "postmaster" is really for inbound mail,
not submission, but there is no code at present to special-case
the behaviour.

-- 
Viktor.


reject connections from hosts without mx record

2015-12-04 Thread sb

Hello,

I received (yet another) SPAM/UCE from an address without MX record.

Although it is not mandatory for a sender to have an MX record,
this RFC loophole is exploited by spammers. Further, I do not want to
receive mail from someone I cannot reply to.

Before writing a milter, I would need to know whether postfix has a 
relevant filter of its own.


This is the spamming host:

> unbound-host -rvD 78-134-2-123.v4.ngi.it
78-134-2-123.v4.ngi.it has address 78.134.2.123 (insecure)
78-134-2-123.v4.ngi.it has no IPv6 address (insecure)
78-134-2-123.v4.ngi.it has no mail handler record (insecure)

This is Postfix:

# postfix/port-25/smtpd[35013]: connect from 
78-134-2-123.v4.ngi.it[78.134.2.123]:3431

...
# postfix/port-25/smtpd[35013]: generic_checks: 
name=reject_unauth_pipelining status=0
# postfix/port-25/smtpd[35013]: generic_checks: 
name=reject_unknown_client_hostname status=0
# postfix/port-25/smtpd[35013]: generic_checks: name=check_client_access 
status=0
# postfix/port-25/smtpd[35013]: generic_checks: 
name=check_reverse_client_hostname_access status=0

# postfix/port-25/smtpd[35013]: >>> END Client host RESTRICTIONS <<<
...

This is the relevant part of main.cf:

smtpd_client_restrictions =
   sleep 1, reject_unauth_pipelining
   reject_unknown_client_hostname
   check_client_access pcre:$meta_directory/fqdns.pcre
   check_reverse_client_hostname_access pcre:$meta_directory/fqrdns.pcre

This is the relevant part of master.cf:

smtp  inet  n   -   -   -   -   smtpd
   -v
   -o syslog_name=postfix/port-25
   -o smtpd_tls_security_level=may
   -o smtpd_sasl_auth_enable=no
   -o smtpd_delay_reject=no
   -o smtpd_milters=${spf_milter},${dkim_milter},${dmarc_milter}
   -o cleanup_service_name=pre-cleanup

Postscreen is currently disabled.

Thank you for your comments.



Re: reject connections from hosts without mx record

2015-12-04 Thread Noel Jones
On 12/4/2015 11:28 AM, sb wrote:
> Hello,
> 
> I received (yet another) SPAM/UCE from an address without MX record.
> 
> Although it is not mandatory for a sender to have an MX record,
> this RFC loophole is exploited by spammers. Further, I do not want to
> receive mail from someone I cannot reply to.

The sender domain must have either an MX or an A record.  You can
reply to a domain with only an A record.

> 
> Before writing a milter, I would need to know whether postfix has a
> relevant filter of its own.

Postfix has no code to distinguish sender domains with no MX only an
A record, and not likely that feature will ever be added.  Sender
domains with neither MX nor A record -- domains you can't reply to
-- can be rejected with reject_unknown_sender_domain.

> 
> This is the spamming host:
> 

...
The client mentioned is currently listed on several blacklists.
Maybe the client wasn't listed at the time you received their spam,
but consider using some dnsbl's in your setup.

> smtp  inet  n   -   -   -   -   smtpd
>-v

verbose logging is almost always a mistake.  The important messages
get drowned in the flood of irrelevant information.

>-o syslog_name=postfix/port-25
>-o smtpd_tls_security_level=may
>-o smtpd_sasl_auth_enable=no
>-o smtpd_delay_reject=no

generally unwise to disable smtpd_delay_reject, except maybe as a
$stress mitigation during an overload/attack.

>-o smtpd_milters=${spf_milter},${dkim_milter},${dmarc_milter}
>-o cleanup_service_name=pre-cleanup 

> 
> Postscreen is currently disabled.

Probably worth investigating using postscreen with a few dnsbls.





  -- Noel Jones


Re: reject connections from hosts without mx record

2015-12-04 Thread sb

On 12/4/15 7:08 PM, Noel Jones wrote:

> The sender domain must have either an MX or an A record.
> You can reply to a domain with only an A record.

If I send mail to the above address, there is no server that can receive it:

> telnet 78.134.2.123 25
Trying 78.134.2.123...

No response given. There is nothing there!

> Postfix has no code to distinguish sender domains with no MX only an 
A record,

> and not likely that feature will ever be added.
> Sender domains with neither MX nor A record -- domains you can't 
reply to --

> can be rejected with reject_unknown_sender_domain.

I had eject_unknown_sender_domain in smtpd_sender_restrictions, and it 
did not work. It is now in  smtpd_client_restrictions.



The documentation says:

> reject_unknown_sender_domain:
>Reject the request when Postfix is not final destination for the 
sender

>address, and the MAIL FROM domain has
>1) no DNS A or MX record, or
>2) a malformed MX record such as a record with a zero-length MX 
hostname.
>The unknown_address_reject_code parameter specifies the numerical 
response
>code for rejected requests (default: 450). The response is always 
450 in
>case of a temporary DNS error. The unknown_address_tempfail_action 
parameter
>specifies the action after a temporary DNS error (default: 
defer_if_permit).


In this case Postfix was final destination for the sender, if I 
understand that

sentence correctly.


> The client mentioned is currently listed on several blacklists. Maybe 
the client wasn't listed
> at the time you received their spam, but consider using some dnsbl's 
in your setup.


I would rather use local filters than remote black lists, for at least 
two reasons:

- they do not use DNSSEC,
- they learn about your incoming addresses.


smtp  inet  n   -   -   -   -   smtpd
-v

verbose logging is almost always a mistake.  The important messages
get drowned in the flood of irrelevant information.


Verbose logging is not a mistake when debugging, which is what I am 
doing at this time.



-o syslog_name=postfix/port-25
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=no
-o smtpd_delay_reject=no

generally unwise to disable smtpd_delay_reject, except maybe as a
$stress mitigation during an overload/attack.


I am running a sensitive site, and need it to be responsive and resilient.
Rapid rejection is necessary, albeit not sufficient.




Let's Encrypt certificates for port 25 SMTP and DANE TLSA

2015-12-04 Thread Viktor Dukhovni
[ FYI, based on text from a recent post to the dane-us...@sys4.de list ]

> Something else to keep in mind with the Let's Encrypt certificates is
> that they have a 90-day lifetime with the automatic renewal process
> starting at sixty days.

Automated replacement might make them entirely unfit for DANE-EE(3).
That is, assuming the automation neglects the necessary DNS update
precondition.

One of the most important features of DANE-EE(3) is that certificates
DO NOT EXPIRE with DANE-EE(3).  You replace it when you are ready
to do it, not when the certificate goes up in smoke.  The expiration
is in the RRSIG end time, not in the certificate.

If you lose that with Let's Encrypt (LE), DO NOT switch to LE.
For port 25 SMTP it'll do more harm than good.  By all means use
LE certificates for port 587 (by configuring different certs for
the MTA and MSA):

  master.cf:
submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_tls_cert_file=$mua_tls_cert_file
  -o smtpd_tls_key_file=$mua_tls_key_file

  main.cf:
mua_tls_cert_file = ... let's encrypt certificate chain + key file name ...

On port 25, go with self-signed certificates "expiring" in the
distant future (20 or more years from now).  One DANE domain whose
administrator "got the memo" has a certificate good for a 1000
years:

Inception = 2014-07-27T14:59:59Z
Expiration = 3013-11-27T14:59:59Z

One way LE for port 25 with DANE can work is if renewal retains
the same private key, and the TLSA records are "3 1 1", making
certificate replacement a non-event, as the key stays the same.

An alternative, is to publish "2 0 1" records for the LE root CA
(which MUST then appear in the server's chain) or "2 1 1" records
for the LE intermediate CA (which must appear in the server's chain,
but that's more typically true anyway).  The reason that I am
suggesting "2 1 1" for intermediates, is that these are often
re-issued with the same key and tend to have lifetimes shorter than
the issuing root.

Using "3 0 1" TLSA records with LE 90 day certificates that are
rotated automatically, sounds like a recipe for disaster, unless
deployment of the new certificate can be delayed (after it is
obtained) and the required DNS updates automated, with the certificate
deployed only once the DNS records have been fielded sufficiently
long.

> Using a Let's Encrypt certificate with DANE TLSA will require an alert
> sysadmin.
> 
> https://community.letsencrypt.org/t/maximum-and-minimum-certificate-lifetimes/264/9

This does not discuss whether a new key is used for each renewal.
Can anyone using LE automated rotation check whether the key stays
the same or not?

-- 
Viktor.


Re: reject connections from hosts without mx record

2015-12-04 Thread Noel Jones
On 12/4/2015 12:57 PM, sb wrote:
> On 12/4/15 7:08 PM, Noel Jones wrote:
> 
>> The sender domain must have either an MX or an A record.
>> You can reply to a domain with only an A record.
> 
> If I send mail to the above address, there is no server that can
> receive it:
> 
>> telnet 78.134.2.123 25
> Trying 78.134.2.123...
> 
> No response given. There is nothing there!

This is a separate issue, a server with no SMTP listener.  Nothing
to do with MX or no MX.

Is this even the IP the sender domain pointed to?  That isn't clear
in your posting.  There is certainly no requirement for an IP that
sends mail also accept mail, many domains large and small use
separate IPs for these two tasks.


> 
>> Postfix has no code to distinguish sender domains with no MX only
> an A record,
>> and not likely that feature will ever be added.
>> Sender domains with neither MX nor A record -- domains you can't
> reply to --
>> can be rejected with reject_unknown_sender_domain.
> 
> I had eject_unknown_sender_domain in smtpd_sender_restrictions, and
> it did not work.

It works as documented and intended.  The domain has an A record and
does not meet the definition of "unknown".


> It is now in  smtpd_client_restrictions.

Where it will never work due to your unrecommended setting of
smtpd_delay_reject=no.


> 
> 
> The documentation says:
> 
>> reject_unknown_sender_domain:
>>Reject the request when Postfix is not final destination for
> the sender
>>address, and the MAIL FROM domain has
>>1) no DNS A or MX record, or
>>2) a malformed MX record such as a record with a zero-length MX
> hostname.
>>The unknown_address_reject_code parameter specifies the
> numerical response
>>code for rejected requests (default: 450). The response is
> always 450 in
>>case of a temporary DNS error. The
> unknown_address_tempfail_action parameter
>>specifies the action after a temporary DNS error (default:
> defer_if_permit).
> 
> In this case Postfix was final destination for the sender, if I
> understand that
> sentence correctly.

This means if the sender domain is your own domain, a job for SPF.


> 
> 
>> The client mentioned is currently listed on several blacklists.
> Maybe the client wasn't listed
>> at the time you received their spam, but consider using some
> dnsbl's in your setup.
> 
> I would rather use local filters than remote black lists, for at
> least two reasons:
> - they do not use DNSSEC,

True, but this scraping the bottom of the "possible threat" barrel.

> - they learn about your incoming addresses.

You send the dnsbl service the connecting client IP address, or
sender domain name for an rhsbl.  This can't be sensitive
information for any internet-connected mail server.


> 
>>> smtp  inet  n   -   -   -   -   smtpd
>>> -v
>> verbose logging is almost always a mistake.  The important messages
>> get drowned in the flood of irrelevant information.
> 
> Verbose logging is not a mistake when debugging, which is what I am
> doing at this time.

Everything you need is in the normal logs.

> 
>>> -o syslog_name=postfix/port-25
>>> -o smtpd_tls_security_level=may
>>> -o smtpd_sasl_auth_enable=no
>>> -o smtpd_delay_reject=no
>> generally unwise to disable smtpd_delay_reject, except maybe as a
>> $stress mitigation during an overload/attack.
> 
> I am running a sensitive site, and need it to be responsive and
> resilient.
> Rapid rejection is necessary, albeit not sufficient.


Unless you're using a severely limited server you're losing the
benefit of delayed rejects for no substantial return.

You're working too hard.  Enable postscreen and a couple blacklists.
 Run it in test mode for a while to see what it does.





  -- Noel Jones


Has anyone added a content filter to Postfix under OS X Server?

2015-12-04 Thread Vicki Brown
I have upgraded my mail "toaster" to use OS X Server. Yippee.

I would like to have more control over the Spam filtering process than X Server 
offers by default.

I have a script (which I hope won't return a "malformed response now) that I 
would like to insert.

I am attempting to understand "http://www.postfix.org/FILTER_README.html 
"

Instructions for a "Simple"content filter suggest adding
-o content_filter=filter:dummy
to the master.cf entry that defines the Postfix SMTP server.

I'm unsure what I should use here, especially given that Apple says these lines 
are all auto-generated and should not be modified:

#  Begin auto-generated section 
# This section of the master.cf file is auto-generated by the Server Admin
#  Mail backend plugin whenever mails settings are modified.
smtp  inet  n   -   n   -   1   postscreen
#   -o content_filter=filter:dummy
smtpd pass  -   -   n   -   -   smtpd
dnsblog   unix  -   -   n   -   0   dnsblog
tlsproxy  unix  -   -   n   -   0   tlsproxy
submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
smtp  unix  -   -   n   -   -   smtp
# === End auto-generated section ===


Alternatively, I could use the Advanced content filter. Iff I understand what 
I'm reading correctly, this appears to be relatively simple to plug into 
master.cf, and it's what APple would use if I turned on their Spam checking 
with amavis,

Does anyone use OS X Server? Have you implemented your own content filter?

Before anyone asks: Wy not just use the Spam Checking Apple includes in Server, 
the answer is: I want more control than just 'tag and deliver'.


-- Vicki Brown
  cfcl.com/vlb




Has anyone added a content filter to Postfix under OS X Server?

2015-12-04 Thread Vicki Brown
And while we're at it, is there (anywhere) an example of an "advanced content 
filter" as described at http://www.postfix.org/FILTER_README.html 
?

The page says:
The job of the content filter is to either bounce mail with a suitable 
diagnostic, or to feed the mail back into Postfix through a dedicated listener 
on port localhost 10026.

The simplest content filter just copies SMTP commands and data between its 
inputs and outputs. If it has a problem, all it has to do is to reply to an 
input of `.' from Postfix with `550 content rejected', and to disconnect 
without sending `.' on the connection that injects mail back into Postfix.

The master.cf configuration implies that the content filter takes at least 2 
arguments:
argv=/path/to/filter localhost 10026
An example of a content filter showing how it uses those arguments would be... 
useful.

- Vicki




I have upgraded my mail "toaster" to use OS X Server. Yippee.

I would like to have more control over the Spam filtering process than X Server 
offers by default.

I have a script (which I hope won't return a "malformed response now) that I 
would like to insert.

I am attempting to understand "http://www.postfix.org/FILTER_README.html 
"

Instructions for a "Simple"content filter suggest adding
-o content_filter=filter:dummy
to the master.cf entry that defines the Postfix SMTP server.

I'm unsure what I should use here, especially given that Apple says these lines 
are all auto-generated and should not be modified:

#  Begin auto-generated section 
# This section of the master.cf file is auto-generated by the Server Admin
#  Mail backend plugin whenever mails settings are modified.
smtp  inet  n   -   n   -   1   postscreen
#   -o content_filter=filter:dummy
smtpd pass  -   -   n   -   -   smtpd
dnsblog   unix  -   -   n   -   0   dnsblog
tlsproxy  unix  -   -   n   -   0   tlsproxy
submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
smtp  unix  -   -   n   -   -   smtp
# === End auto-generated section ===


Alternatively, I could use the Advanced content filter. Iff I understand what 
I'm reading correctly, this appears to be relatively simple to plug into 
master.cf, and it's what APple would use if I turned on their Spam checking 
with amavis,

Does anyone use OS X Server? Have you implemented your own content filter?

Before anyone asks: Wy not just use the Spam Checking Apple includes in Server, 
the answer is: I want more control than just 'tag and deliver'.


-- Vicki Brown
  cfcl.com/vlb 




Re: Has anyone added a content filter to Postfix under OS X Server?

2015-12-04 Thread Viktor Dukhovni
On Fri, Dec 04, 2015 at 12:48:16PM -0800, Vicki Brown wrote:

> I am attempting to understand "http://www.postfix.org/FILTER_README.html";
> 
> Instructions for a "Simple"content filter suggest adding
> -o content_filter=filter:dummy
> to the master.cf entry that defines the Postfix SMTP server.

Correct.

> I'm unsure what I should use here, especially given that Apple says these
> lines are all auto-generated and should not be modified:

*After* defining a corresponding "filter" transport as described
in the README file, verbatim what is written in FILTER_README.html,
despite whatever Apple might lead you to believe.

> #  Begin auto-generated section 
> # This section of the master.cf file is auto-generated by the Server Admin
> #  Mail backend plugin whenever mails settings are modified.
> smtp  inet  n   -   n   -   1   postscreen
> #   -o content_filter=filter:dummy

Either disable the plugin, or configure it enable the content_filter.

> Alternatively, I could use the Advanced content filter. If I understand
> what I'm reading correctly, this appears to be relatively simple to plug
> into master.cf, and it's what Apple would use if I turned on their Spam
> checking with amavis,

The advanced filter is also more efficient.

> Before anyone asks: Wy not just use the Spam Checking Apple includes in
> Server, the answer is: I want more control than just 'tag and deliver'.

Perhaps that's also configurable with the bundled filter, but not
that content_filters can't reject mail (it is too late).  You need
a proxy filter or milter to reject.  If you want to quarantine,
that's still possible with suitable content_filter software,
otherwise it is tag and deliver (or, not recommended: discard).

-- 
Viktor.


Re: reject connections from hosts without mx record

2015-12-04 Thread Bill Cole

On 4 Dec 2015, at 13:57, sb wrote:


On 12/4/15 7:08 PM, Noel Jones wrote:

[...]


I had eject_unknown_sender_domain in smtpd_sender_restrictions, and it 
did not work.

It is now in  smtpd_client_restrictions.


Which is wrong. See 'man 5 postconf' and the file SMTPD_ACCESS_README in 
the Postfix documentation.



-o syslog_name=postfix/port-25
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=no
-o smtpd_delay_reject=no

generally unwise to disable smtpd_delay_reject, except maybe as a
$stress mitigation during an overload/attack.


I am running a sensitive site, and need it to be responsive and 
resilient.


Yet you have chosen an unwise configuration that CANNOT work and is 
clearly documented as being  non-working. It makes your site LESS 
resilient.



Rapid rejection is necessary, albeit not sufficient.


That isn't a meaningful reason to use "smtpd_delay_reject=no"

The "delay" is operationally trivial: at most ~8x the RTT between you 
and the client, for a rejection that could be done by 
smtpd_client_restrictions. Unlikely to be more than a second. More 
importantly, rejecting before the RCPT phase will cause some rejected 
clients using shoddy spamware to retry sending, in some cases at high 
frequency for extended periods. In addition, if you are concerned about 
information leakage, rejecting before RCPT informs a rejected sender 
that pays attention to their rejections that you are rejecting based 
solely on the basis of information you have at that point of rejection. 
Turning that around, using the smtpd_delay_reject=yes default allows you 
to make more complex decisions about accepting and rejecting messages 
which need not be made entirely clear to untrusted senders.