Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?

[lists]

>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>
> With Postfix 2.11 or later, just leave this empty, session tickets work
> better.


Viktor, thanks

does 'leave empty' means have it present on main.cf up to '=' ?
as so ?

smtpd_tls_session_cache_database =

Re: policyd-spf tip

[Scott Kitterman]

On December 25, 2017 10:25:42 PM EST, "li...@lazygranch.com" 
 wrote:
>I figured I would middle post, so skip down a bit.
>
>On Mon, 25 Dec 2017 11:56:02 -0800
>Gao  wrote:
>
>> I quickly checked my policyd-spf setting after read your email. I 
>> noticed that the policyd-spf in my system is not running as a
>service.
>> 
>> I guess you are using debian. I am using CentOS7 and I installed 
>> pypolicyd-spf from EPEL. So is there a big advantage to running it as
>> a daemon service? How do I enable it as a service? Obviously yum
>> install doesn't take care of the service setup.
>> 
>> Gao
>
>I'm on Centos 7. This is my uname -a.
>Linux servername 3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40
>UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
>Looking at ps aux, policyd-spf is not running. In the strict sense,
>that means it is not a daemon.
>https://en.wikipedia.org/wiki/Daemon_(computing)
>However all references to policyd and policyd-spf are as daemons.  
>
>I'm new to Centos. I run opensuse on my desktop and had presently have
>my VPS server on FreeBSD. Due to update issues, I decided to abandon
>FreeBSD for Centos, since I'm more familiar with Linux than BSD these
>days.

Despite the name, it's not a daemon.  When I started the project, I anticipated 
that in it's future, but later decided staying with using spawn was a good 
idea.  I also decided renaming wasn't worth the trouble.

Scott K

Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?

[Viktor Dukhovni]

> On Dec 26, 2017, at 1:39 AM, li...@sbt.net.au wrote:

Overall quite standard.  Nothing to worry about.

> smtpd_tls_session_cache_timeout = 36000s

10 hours is perhaps too long to be useful. Just let the default stand.

> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

With Postfix 2.11 or later, just leave this empty, session tickets work
better.

> smtp_tls_security_level = may
> smtp_tls_note_starttls_offer = yes

The second is not needed.

> smtp_tls_session_cache_timeout = 3600s
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

By way of contrast these are fine.

-- 
Viktor.

Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?

[Viktor Dukhovni]

> On Dec 26, 2017, at 1:34 AM, li...@sbt.net.au wrote:
> 
>> 
>> Generally no.  There are some SMTP clients that both TLS,

s/both/botch/

Hope that's less confusing.

>> they'll either retry in the clear, or they are likely shoddy
>> spamware.
>> Other log messages will show the IP address of the client.  If you weren't
>> expecting any email from that client, just ignore this.
> 
> 
> thanks, both were from same no hostname IP address
> 
> # host 125.212.217.214
> Host 214.217.212.125.in-addr.arpa. not found: 3(NXDOMAIN)

According to "whois" that's an IP address in Vietnam...

-- 
Viktor.

Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?

[lists]

>> On Dec 25, 2017, at 8:57 PM, li...@sbt.net.au wrote:

> This of course assumes you've not configured particularly exotic TLS
> settings on your end.

Viktor,
thanks again, I hope it's not exotic, not to my knowledge, anyhow:

that that show what it is ? suggestions and corrections appreciated

# grep tls main.cf

smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_key_file = /etc/letsencrypt/live/geko.sbt.net.au/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/geko.sbt.net.au/fullchain.pem
smtpd_tls_session_cache_timeout = 36000s
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_random_source = dev:/dev/urandom
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_timeout = 3600s
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?

[lists]

>> On Dec 25, 2017, at 8:57 PM, li...@sbt.net.au wrote:
>>
>> anything to worry about ?
>
> Generally no.  There are some SMTP clients that both TLS,
> they'll either retry in the clear, or they are likely shoddy
> spamware.
> Other log messages will show the IP address of the client.  If you weren't
> expecting any email from that client, just ignore this.


Viktor,

thanks, both were from same no hostname IP address

# host 125.212.217.214
Host 214.217.212.125.in-addr.arpa. not found: 3(NXDOMAIN)

log shows:

# grep "Dec 25 08:39" /var/log/maillog
Dec 25 08:39:12 geko postfix/smtpd[9700]: connect from
unknown[125.212.217.214]
Dec 25 08:39:17 geko postfix/smtpd[9700]: Anonymous TLS connection
established from unknown[125.212.217.214]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 25 08:39:18 geko postfix/smtpd[9701]: connect from
unknown[125.212.217.214]
Dec 25 08:39:19 geko postfix/smtpd[9701]: Anonymous TLS connection
established from unknown[125.212.217.214]: TLSv1 with cipher
ECDHE-RSA-AES256-SHA (256/256 bits)
Dec 25 08:39:19 geko postfix/smtpd[9701]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:19 geko postfix/smtpd[9701]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=1 commands=2
Dec 25 08:39:20 geko postfix/smtpd[9701]: connect from
unknown[125.212.217.214]
Dec 25 08:39:21 geko postfix/smtpd[9701]: SSL_accept error from
unknown[125.212.217.214]: -1
Dec 25 08:39:21 geko postfix/smtpd[9701]: warning: TLS library problem:
error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:640:
Dec 25 08:39:21 geko postfix/smtpd[9701]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:21 geko postfix/smtpd[9701]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=0/1 commands=1/2
Dec 25 08:39:23 geko postfix/smtpd[9701]: connect from
unknown[125.212.217.214]
Dec 25 08:39:23 geko postfix/smtpd[9700]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:23 geko postfix/smtpd[9700]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=1 commands=2
Dec 25 08:39:24 geko postfix/smtpd[9701]: SSL_accept error from
unknown[125.212.217.214]: -1
Dec 25 08:39:24 geko postfix/smtpd[9701]: warning: TLS library problem:
error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version
number:s3_srvr.c:977:
Dec 25 08:39:24 geko postfix/smtpd[9701]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:24 geko postfix/smtpd[9701]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=0/1 commands=1/2
Dec 25 08:39:25 geko postfix/smtpd[9700]: connect from
unknown[125.212.217.214]
Dec 25 08:39:26 geko postfix/smtpd[9700]: Anonymous TLS connection
established from unknown[125.212.217.214]: TLSv1.1 with cipher
ECDHE-RSA-AES256-SHA (256/256 bits)
Dec 25 08:39:27 geko postfix/smtpd[9700]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:27 geko postfix/smtpd[9700]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=1 commands=2
Dec 25 08:39:28 geko postfix/smtpd[9701]: connect from
unknown[125.212.217.214]
Dec 25 08:39:29 geko postfix/smtpd[9701]: Anonymous TLS connection
established from unknown[125.212.217.214]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 25 08:39:29 geko postfix/smtpd[9701]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:29 geko postfix/smtpd[9701]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=1 commands=2
Dec 25 08:39:29 geko postfix/smtpd[9700]: connect from
unknown[125.212.217.214]
Dec 25 08:39:30 geko postfix/smtpd[9700]: lost connection after UNKNOWN
from unknown[125.212.217.214]
Dec 25 08:39:30 geko postfix/smtpd[9700]: disconnect from
unknown[125.212.217.214] unknown=0/1 commands=0/1
Dec 25 08:39:30 geko postfix/smtpd[9701]: connect from
unknown[125.212.217.214]
Dec 25 08:39:32 geko postfix/smtpd[9701]: Anonymous TLS connection
established from unknown[125.212.217.214]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 25 08:39:32 geko postfix/smtpd[9701]: lost connection after STARTTLS
from unknown[125.212.217.214]
Dec 25 08:39:32 geko postfix/smtpd[9701]: disconnect from
unknown[125.212.217.214] ehlo=1 starttls=1 commands=2
Dec 25 08:39:36 geko postfix/smtpd[9700]: connect from
unknown[125.212.217.214]
Dec 25 08:39:36 geko postfix/smtpd[9700]: lost connection after CONNECT
from unknown[125.212.217.214]
Dec 25 08:39:36 geko postfix/smtpd[9700]: disconnect from
unknown[125.212.217.214] commands=0/0
Dec 25 08:39:39 geko postfix/smtpd[9701]: connect from
unknown[125.212.217.214]
Dec 25 08:39:41 geko postfix/smtpd[9700]: connect from
unknown[125.212.217.214]
Dec 25 08:39:41 geko postfix/smtpd[9700]: lost connection after UNKNOWN
from unknown[125.212.217.214]
Dec 25 08:39:41 geko postfix/smtpd[9700]: disconnect from
unknown[125.212.217.214] unknown=0/2 commands=0/2
Dec 25 08:39:45 geko postfix/smtpd[9701]: lost connection after CONNECT
from 

Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?

[Viktor Dukhovni]

> On Dec 25, 2017, at 8:57 PM, li...@sbt.net.au wrote:
> 
> anything to worry about ?

Generally no.  There are some SMTP clients that both TLS,
they'll either retry in the clear, or they are likely shoddy
spamware.

> # grep 'TLS library problem' /var/log/maillog*
> /var/log/maillog:Dec 25 08:39:21 geko postfix/smtpd[9701]: warning: TLS
> library problem: error:140760FC:SSL
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:640:
> /var/log/maillog:Dec 25 08:39:24 geko postfix/smtpd[9701]: warning: TLS
> library problem: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong
> version number:s3_srvr.c:977:
> /var/log/maillog-20171224:Dec 21 05:25:49 geko postfix/smtpd[20642]:
> warning: TLS library problem: error:140760FC:SSL
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:640:
> /var/log/maillog-20171224:Dec 21 05:25:54 geko postfix/smtpd[20642]:
> warning: TLS library problem: error:1408A10B:SSL
> routines:ssl3_get_client_hello:wrong version number:s3_srvr.c:977:


Other log messages will show the IP address of the client.  If you weren't
expecting any email from that client, just ignore this.

This of course assumes you've not configured particularly exotic TLS
settings on your end.

-- 
Viktor.

Re: policyd-spf tip

[li...@lazygranch.com]

I figured I would middle post, so skip down a bit.

On Mon, 25 Dec 2017 11:56:02 -0800
Gao  wrote:

> I quickly checked my policyd-spf setting after read your email. I 
> noticed that the policyd-spf in my system is not running as a service.
> 
> I guess you are using debian. I am using CentOS7 and I installed 
> pypolicyd-spf from EPEL. So is there a big advantage to running it as
> a daemon service? How do I enable it as a service? Obviously yum
> install doesn't take care of the service setup.
> 
> Gao

I'm on Centos 7. This is my uname -a.
Linux servername 3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Looking at ps aux, policyd-spf is not running. In the strict sense,
that means it is not a daemon.
https://en.wikipedia.org/wiki/Daemon_(computing)
However all references to policyd and policyd-spf are as daemons.  

I'm new to Centos. I run opensuse on my desktop and had presently have
my VPS server on FreeBSD. Due to update issues, I decided to abandon
FreeBSD for Centos, since I'm more familiar with Linux than BSD these
days.



> 
> On 2017-12-24 22:02, li...@lazygranch.com wrote:
> > There are many "problem solving pages" on the interwebs that have
> > wrong information on setting up policyd-spf. The key to make sure
> > you use consistent names in both main.cf and master.cf. Yeah, I
> > know, I'm preaching to the choir, but hopefully the next person
> > with a set up problem finds this message in a search.
> > 
> > In master.cf:
> > policyunix  -   n   n   -   0   spawn
> >  user=nobody  argv=/usr/libexec/postfix/policyd-spf
> > /etc/policyd-spf/policyd-spf.conf
> > 
> > Note you need to make sure the conf file location is correct.
> > 
> > In main.cf:
> > smtpd_recipient_restrictions =
> >   permit_sasl_authenticated,
> >   permit_mynetworks,
> >   reject_unauth_destination,
> >   reject_rbl_client zen.spamhaus.org,
> >   check_policy_service unix:private/policy,
> >   permit
> > 
> > policy_time_limit = 3600
> > 
> > The word "policy" needs to be consistent in all three locations. For
> > example, this would be wrong:
> >   check_policy_service unix:private/policyd-spf,
> > 
> > Also wrong would be:
> > policyd_time_limit = 3600
> > 
> > 
> > In postfix, systemctl status postfix should indicate the policyd-spf
> > daemon was started:
> > 
> > ● postfix.service - Postfix Mail Transport
> > Agent Loaded: loaded (/usr/lib/systemd/system/postfix.service;
> > enabled; vendor preset: disabled) Active: active (running) since
> > Mon 2017-12-25 05:28:11 UTC; 16s ago Process: 7661
> > ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
> > Process: 7681 ExecStart=/usr/sbin/postfix start (code=exited,
> > status=0/SUCCESS) Process: 7679
> > ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited,
> > status=0/SUCCESS) Process: 7677
> > ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited,
> > status=0/SUCCESS) Main PID: 7755 (master)
> > CGroup: /system.slice/postfix.service
> > ├─7755 /usr/libexec/postfix/master -w ├─7756 pickup -l -t unix -u
> > ├─7757 qmgr -l -t unix -u ├─7758 smtpd -n smtp -t inet -u -o
> > stress= ├─7759 proxymap -t unix -u ├─7760 tlsmgr -l -t unix -u
> >├─7761 anvil -l -t unix -u
> >├─7763 trivial-rewrite -n rewrite -t unix -u
> >├─7764 spawn -z -n policy -t unix user=nobody
> > argv=/usr/libexec/postfix/policyd-spf /etc/policyd-spf/policyd-spf.conf
> > ├─7765 /usr/bin/python /usr/libexec/postfix/policyd-spf
> > /etc/policyd-spf/policyd-spf.conf
> > ├─7766 cleanup -z -t unix -u └─7767 virtual -t unix
> > -
> > 
> > And proof it is working from an email header:
> > Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
> > client-ip=66.163.187.148;
> > helo=sonic316-22.consmr.mail.ne1.yahoo.com;
> > envelope-from=m...@yahoo.com; receiver=m...@mydomain.com  

TLS library problem: error:140760FC:SSL routines, is it a problem ?

[lists]

whilst installing/configuring 2.1 to 3.2.x migration
(using 2.1 main/master on 3.2 install), noticed these errors:

anything to worry about ?


# grep 'TLS library problem' /var/log/maillog*
/var/log/maillog:Dec 25 08:39:21 geko postfix/smtpd[9701]: warning: TLS
library problem: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:640:
/var/log/maillog:Dec 25 08:39:24 geko postfix/smtpd[9701]: warning: TLS
library problem: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong
version number:s3_srvr.c:977:
/var/log/maillog-20171224:Dec 21 05:25:49 geko postfix/smtpd[20642]:
warning: TLS library problem: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:640:
/var/log/maillog-20171224:Dec 21 05:25:54 geko postfix/smtpd[20642]:
warning: TLS library problem: error:1408A10B:SSL
routines:ssl3_get_client_hello:wrong version number:s3_srvr.c:977:

# egrep '(error|fatal|panic):' /var/log/maillog
Dec 25 08:39:21 geko postfix/smtpd[9701]: warning: TLS library problem:
error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:640:
Dec 25 08:39:24 geko postfix/smtpd[9701]: warning: TLS library problem:
error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version
number:s3_srvr.c:977:

 egrep '(warning|error|fatal|panic):' /var/log/maillog

returns many lines, seem mainly like this:

Dec 26 11:56:52 geko postfix/smtpd[9572]: warning: hostname
zg-1222a-130.stretchoid.com does not resolve to address 45.55.6.96: Name
or service not known
Dec 26 12:07:45 geko postfix/smtpd[9758]: warning: unknown[1.195.247.204]:
SASL LOGIN authentication failed: UGFzc3dvcmQ6
Dec 26 12:07:54 geko postfix/smtpd[9758]: warning: unknown[1.195.247.204]:
SASL LOGIN authentication failed: UGFzc3dvcmQ6
Dec 26 12:08:08 geko postfix/smtpd[9758]: warning: unknown[1.195.247.204]:
SASL LOGIN authentication failed: UGFzc3dvcmQ6

migrating 2.1 to 3.x, what else is needed ?

[lists]

I'd like to update and migrate my current Postfix 2.1 to an up to date
version, it's a Postfix/Dovecot/MySQL/smtp auth/ virtual domains/users

I've installed new Centos 7 with ghettoforge postfix 3.2.4 /dovecot, and,
copied over /etc/postfix etc/dovecot, after some minor edits (remove
policyd 1.x, add postfwd, edit IPs/host names, letsencrypt, etc)

it seems to work OK, only some warnings, can send/receive

so I should now run this, yes ? "postconf compatibility_level=2"

what else should I or must I do, what else is suggested/recommended ?

is my (largely unconfigured as yet) postfwd in correct place ?

# postfix reload

Dec 26 11:14:07 geko postfix[8521]: Postfix is running with
backwards-compatible default settings
Dec 26 11:14:07 geko postfix[8521]: See
http://www.postfix.org/COMPATIBILITY_README.html for details
Dec 26 11:14:07 geko postfix[8521]: To disable backwards compatibility use
"postconf compatibility_level=2" and "postfix
 reload"
Dec 26 11:14:07 geko postfix/postfix-script[8527]: refreshing the Postfix
mail system
Dec 26 11:14:07 geko postfix/master[1298]: reload -- version 3.2.4,
configuration /etc/postfix

postconf -n
-

address_verify_sender = $double_bounce_sender
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_min_user = no
allow_percent_hack = no
anvil_rate_time_unit = 1800s
biff = no
body_checks = pcre:/etc/postfix/body_checks
body_checks_size_limit = 15
bounce_queue_lifetime = 4h
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 0h
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
enable_original_recipient = no
header_checks = pcre:/etc/postfix/header_checks.pcre
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/libexec/dovecot/deliver
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_backoff_time = 4000s
maximal_queue_lifetime = 4h
message_size_limit = 30971520
mime_header_checks = pcre:$config_directory/mime_headers.pcre
minimal_backoff_time = 300s
mydestination = $myhostname, localhost, localhost.localdomain,
localhost.$myhostname
mydomain = sbt.net.au
myhostname = geko.sbt.net.au
mynetworks = 163.47.110.6 163.47.110.7 127.0.0.1
myorigin = geko.sbt.net.au
newaliases_path = /usr/bin/newaliases.postfix
proxy_read_maps = $canonical_maps $lmtp_generic_maps $local_recipient_maps
$mydestination $mynetworks $recipient_bcc_maps $recipient_canonical_maps
$relay_domains $relay_recipient_maps $relocated_maps $sender_bcc_maps
$sender_canonical_maps $smtp_generic_maps $smtpd_sender_login_maps
$transport_maps $virtual_alias_domains $virtual_alias_maps
$virtual_mailbox_domains $virtual_mailbox_maps $smtpd_sender_restrictions
queue_directory = /var/spool/postfix
queue_run_delay = 300s
readme_directory = /usr/share/doc/postfix3-3.2.4/README_FILES
recipient_bcc_maps =
proxy:mysql:/etc/postfix/mysql/recipient_bcc_maps_user.cf,
proxy:mysql:/etc/postfix/mysql/recipient_bcc_maps_domain.cf
recipient_delimiter = +
relay_domains = $mydestination,
proxy:mysql:/etc/postfix/mysql/relay_domains.cf
sender_bcc_maps = proxy:mysql:/etc/postfix/mysql/sender_bcc_maps_user.cf,
proxy:mysql:/etc/postfix/mysql/sender_bcc_maps_domain.cf
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp-amavis_destination_recipient_limit = 1
smtp_data_init_timeout = 240s
smtp_data_xfer_timeout = 600s
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_client_connection_rate_limit = 50
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
check_helo_access pcre:/etc/postfix/helo_access.pcre
smtpd_recipient_restrictions = reject_unknown_sender_domain,
reject_unknown_recipient_domain, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unlisted_recipient, permit_mynetworks,
check_sasl_access hash:/etc/postfix/sasl_access permit_sasl_authenticated,
reject_unauth_destination, check_policy_service inet:127.0.0.1:10040,
check_recipient_access hash:/etc/postfix/recipient_no_checks,
check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks, check_sender_access
hash:/etc/postfix/sender_checks, check_client_access
hash:/etc/postfix/client_checks, check_client_access
pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org,
reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender

Re: policyd-spf tip

[Gao]

I quickly checked my policyd-spf setting after read your email. I 
noticed that the policyd-spf in my system is not running as a service.


I guess you are using debian. I am using CentOS7 and I installed 
pypolicyd-spf from EPEL. So is there a big advantage to running it as a 
daemon service? How do I enable it as a service? Obviously yum install 
doesn't take care of the service setup.


Gao

On 2017-12-24 22:02, li...@lazygranch.com wrote:

There are many "problem solving pages" on the interwebs that have wrong
information on setting up policyd-spf. The key to make sure you use
consistent names in both main.cf and master.cf. Yeah, I know, I'm
preaching to the choir, but hopefully the next person with a set up
problem finds this message in a search.

In master.cf:
policyunix  -   n   n   -   0   spawn
 user=nobody  argv=/usr/libexec/postfix/policyd-spf
/etc/policyd-spf/policyd-spf.conf

Note you need to make sure the conf file location is correct.

In main.cf:
smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_rbl_client zen.spamhaus.org,
  check_policy_service unix:private/policy,
  permit

policy_time_limit = 3600

The word "policy" needs to be consistent in all three locations. For
example, this would be wrong:
  check_policy_service unix:private/policyd-spf,

Also wrong would be:
policyd_time_limit = 3600


In postfix, systemctl status postfix should indicate the policyd-spf
daemon was started:

● postfix.service - Postfix Mail Transport
Agent Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled;
vendor preset: disabled) Active: active (running) since Mon 2017-12-25
05:28:11 UTC; 16s ago Process: 7661 ExecStop=/usr/sbin/postfix stop
(code=exited, status=0/SUCCESS) Process: 7681
ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
Process: 7679 ExecStartPre=/usr/libexec/postfix/chroot-update
(code=exited, status=0/SUCCESS) Process: 7677
ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited,
status=0/SUCCESS) Main PID: 7755 (master)
CGroup: /system.slice/postfix.service
├─7755 /usr/libexec/postfix/master -w ├─7756 pickup -l -t unix -u
├─7757 qmgr -l -t unix -u ├─7758 smtpd -n smtp -t inet -u -o
stress= ├─7759 proxymap -t unix
-u ├─7760 tlsmgr -l -t unix -u
   ├─7761 anvil -l -t unix -u
   ├─7763 trivial-rewrite -n rewrite -t unix -u
   ├─7764 spawn -z -n policy -t unix user=nobody
argv=/usr/libexec/postfix/policyd-spf /etc/policyd-spf/policyd-spf.conf
├─7765 /usr/bin/python /usr/libexec/postfix/policyd-spf
/etc/policyd-spf/policyd-spf.conf
├─7766 cleanup -z -t unix -u └─7767 virtual -t unix
-

And proof it is working from an email header:
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
client-ip=66.163.187.148; helo=sonic316-22.consmr.mail.ne1.yahoo.com;
envelope-from=m...@yahoo.com; receiver=m...@mydomain.com

Re: Temporarily stop mail delivery

[Philip Paeps]

On 2017-12-25 13:58:53 (-0500), Wietse Venema wrote:

Wietse Venema:

Black Sheep:
> Is there a simple way to temporarily stop postfix delivering mail
> into the /var/vmail mail boxes, instead queueing them up? The
> purpose being to get a clean backup of /var/vmail without stopping
> receipt of mail from the internet. Then restart mail delivery so
> the queue is emptied into the appropriate local mail boxes?

/etc/postfix/main.cf
transport_maps = static:{4.3.0 Mail service unavailable}


Sorry that should be:

transport_maps = static:{retry:4.3.0 Mail service unavailable}


That will stop Postfix from acccepting mail from the network.


Oh wow.  Thanks for that tip!

I really need to get used to start using more of these static: maps.  I 
have a couple single-entry /^.*$/ pcre: tables which should probably all 
be static:.


Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Re: Temporarily stop mail delivery

[Wietse Venema]

Wietse Venema:
> Black Sheep:
> > Is there a simple way to temporarily stop postfix delivering mail
> > into the /var/vmail mail boxes, instead queueing them up? The
> > purpose being to get a clean backup of /var/vmail without stopping
> > receipt of mail from the internet. Then restart mail delivery so
> > the queue is emptied into the appropriate local mail boxes?
> 
> /etc/postfix/main.cf
> transport_maps = static:{4.3.0 Mail service unavailable}

Sorry that should be:

transport_maps = static:{retry:4.3.0 Mail service unavailable}

> That will stop Postfix from acccepting mail from the network.
> 
>   Wietse
> 

Re: Temporarily stop mail delivery

[Viktor Dukhovni]

> On Dec 25, 2017, at 5:14 AM, Black Sheep  
> wrote:
> 
> Is there a simple way to temporarily stop postfix delivering mail into the 
> /var/vmail mail boxes, instead queueing them up? The purpose being to get a 
> clean backup of /var/vmail without stopping receipt of mail from the 
> internet. Then restart mail delivery so the queue is emptied into the 
> appropriate local mail boxes?


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

   # Defer delivery via all transports that store mail locally,
   # "smtp" and "relay" delivery mail to remote systems and can
   # continue.  Add or remove elements to match what's used from
   # master.cf
   #
   defer_transports = local, virtual, lmtp, maildrop

changing this requires a "reload".

-- 
Viktor.

Re: Postfix vs Exim

[Viktor Dukhovni]

> On Dec 25, 2017, at 3:31 AM, vonProteus  
> wrote:
> 
> With one is better and why do you think so?
> I’m going to chose one and would like to know your opinion

Disclaimer: I am a Postfix developer and user, and hang out on the
Exim lists only because I've contributed some DANE-related code to
Exim.

With the above noted, I find the Exim source code a distasteful mess,
and observe in Exim a great deal more bug reports and bug fix activity,
which backs up my sense that the code quality in Exim is lower than in
Postfix.

Most users probably don't care about code quality and don't seem to
mind security patches now and then.  What sets Exim apart in terms
of features is that it has a lot more built-in controls.  There are
things you can do in Exim directly that would require a policy service,
milter or content filter in Postfix.  What sets Postfix apart is that
its built-in features are clean and easier to use and understand.
Postfix is not monolithic, and the combination of master-server plus
queue-manager and delivery agents outperforms Exim on busy servers.

The price of Exim's built-in controls is that the configuration
language is a fragile mess of nested curly brackets. Some care is
required to avoid issues akin to "SQL injection" where literal
external data might get confused with Exim's quoting and list
construction syntax.

Postfix, for example, supports LDAP groups with indirect
members as DN references and dynamic groups via query URIs
via the "special_result_attribute" lookup table property.
This required specialized internal code to present a high
level abstraction to the user.  In Exim, you get a raw
LDAP lookup interface, and get to split the result set
yourself, and then do any desired DN recursion.  In theory,
this is more flexible, you're in charge.  In practice it
can be much harder to get the basics right.

My impression is that Exim is more widely used by individual
users hosting their own domain, while Postfix is more widely
used by small businesses, service providers.  There is of course
a great deal of overlap, but I would estimate that Exim has more
MX hosts, and Postfix handles more mail.

If Postfix is sufficient for your needs, you'll find it is easier
to use and more reliable.  If you need fancy conditional logic
and want it all built-in, Exim may be more to your liking, but
you've been warned, it is easier to misconfigure, possibly in
ways that compromise security, so be careful.

-- 
Viktor.

Re: Temporarily stop mail delivery

[Anvar Kuchkartaev]

  Before taking backup or other action that requires stopping mail delivery I usually just stop all postfix instances which MX record points. Anvar Kuchkartaev an...@anvartay.comFrom: Black SheepSent: lunes, 25 de diciembre de 2017 11:14To: Postfix users‎Subject: Temporarily stop mail delivery




Is there a simple way to temporarily stop postfix delivering mail into the /var/vmail mail boxes, instead queueing them up? The purpose being to get a clean backup of /var/vmail without stopping receipt of mail from the internet. Then restart mail delivery so the queue is emptied into the appropriate local mail boxes?

Martin

Re: Postfix vs Exim

[Stephen Satchell]

On 12/25/2017 12:31 AM, vonProteus wrote:

With one is better and why do you think so?
I’m going to chose one and would like to know your opinion


Interesting you should ask this on the Postfix mailing list.  Especially 
since because there is no "right" answer.


Over the years, I've worked with sendmail/procmail, Postfix, Exim, and 
Qmail.  The reason is that I worked at a web hosting company that bought 
into Web products that featured customer control panels, and the various 
control panel systems used these mailers as part of their "total package".


Sendmail is just plain cryptic.  In response to my complaint about the 
complexity of the sendmail configurtion file, I was presented with a 
copy of O'Reilly's sendmail book with this inscription:  "It's not that 
hard" -- Eric Allman.  In my library I have books for all the mail 
daemons...and the sendmail shelf space is larger then other three 
*combined*.


Qmail is a Dr. Dan Bernstein (University of Illinois at Chicago) 
creation.  As such, it's focused on security (the goad for it's birth in 
1997).  Instead of having one large configuration file, it breaks up 
configuration into a bunch of small files.  In my mind, this mindset 
makes saving the state of the mailer a daunting task, as well as needing 
a rather complex "cheat sheet" to know where to find things.  (As an 
aside, the Unix utility ptx(1) proved extremely useful -- look it up.)


Exim is the baby of Philip Hazel, University of Cambridge (England). 
It's been awhile since I have approached Exim, but what I do recall is 
that I didn't like the feel of it.  (This is probably just me, not a 
knock on the daemon.)  The configuration is contained in a single file, 
separated into sections.  My one excursion into Exim was to configure it 
to smart-host all mail through a edge MTA to throttle flow to specific 
endpoints (AOL, HotMail, Google, and so forth -- and the edge MTA was 
Postfix!)


Postfix is the product of Wietse Venema (IBM Research).  When I was the 
first customer of DSL in northern Nevada, I was stuck with Pacific 
Telesys as my e-mail provider.  After finding many of my e-mails blocked 
because of PacTel's reputation, I set up my own mail server.  Of the 
options available, I picked PostFix...and haven't regretted that choice. 
 Postfix uses a pair of configuration files, plus a number of small 
databases.


There are other MTAs available, but they cost .  Like Microsoft 
Exchange.  'Nuff said.


Then there are other opinions:

https://www.tecmint.com/best-mail-transfer-agents-mta-for-linux/
https://en.wikipedia.org/wiki/Comparison_of_mail_servers


Assume for the moment I dismiss sendmail and the non-free MTAs  as 
possibilities.  Of the remaining three daemons, it's hard to choose 
which one is "better".  It boils down to a matter of taste, and your 
needs.  All three of the options have their grounding in academia, Exim 
and Qmail more so than Postfix.  All three have regular updates, 
including security updates.  All three have vibrant user communities.


In my networks and at my customers' sites, I run Postfix with Dovecot. 
This may indeed be the result of "baby duck syndrome", because it was 
the option I picked as most readily available to me with Red Hat Linux 5 
(vice Sendmail) 'way back in the Dark Ages.  Postfix was my choice at a 
web hosting company as the edge MTA when I was fighting blocklists and 
large mail operators and having to deal with a ton of spam.  (N.B.: it 
helps to know Perl or Python to code custom filters, if you need them.)


My suggestion:  take a look at the on-line documentation for each 
program, or go to a well-stocked library and leaf through the O'Reilly 
and Que books for each...and "for Dummies" books if you find 'em. 
(Thank you, Mac McCarthy, for starting that imprint.)  Then decide which 
ones fits you and your needs best.

Re: Temporarily stop mail delivery

[Wietse Venema]

Black Sheep:
> Is there a simple way to temporarily stop postfix delivering mail
> into the /var/vmail mail boxes, instead queueing them up? The
> purpose being to get a clean backup of /var/vmail without stopping
> receipt of mail from the internet. Then restart mail delivery so
> the queue is emptied into the appropriate local mail boxes?

/etc/postfix/main.cf
transport_maps = static:{4.3.0 Mail service unavailable}

That will stop Postfix from acccepting mail from the network.

Wietse

Re: Temporarily stop mail delivery

[Black Sheep]

Thanks, looks good. I’d think the reload probably is necessary.

Martin

On 25 Dec 2017, 10:30 +, Ralph Seichter , 
wrote:
> On 25.12.2017 11:14, Black Sheep wrote:
>
> > Is there a simple way to temporarily stop postfix delivering mail into
> > the /var/vmail mail boxes [...]
>
> The following method works (I'm not certain if reloading is even
> required):
>
> #!/bin/bash
> # Temporarily disable local delivery
> postconf -e defer_transports=local && postfix reload
> [... Your backup operations here ...]
> # Re-enable local delivery
> postconf -e defer_transports='' && postfix reload
>
> -Ralph

Re: Postfix vs Exim

[Philip Paeps]

[Please don't top-post.  Formatting repaired.]

On 2017-12-25 11:20:40 (+0100), vonProteus wrote:

On Mon, Dec 25, 2017 at 10:04 AM, Marat Khalili  wrote:
Flamebait question, but I happened to configure both (repository 
versions) recently, so here's one opinion. Both are useable, and used. 
Exim is sold as easier to configure, but IMO it doesn't deliver on 
this - probably simple config is just an impossible thing for 
universal SMTP MTA. On the other hand, Postfix has larger internet 
share and more resources on the web dedicated to it. Therefore I 
usually go for postfix (once you learned it, it's not that hard), and 
only use exim if there's no postfix in distribution repository.


my ultimate goal is to configure MTA in that way that i'm able to use 
it as a mail relay station

sorry for my not fully technical and poor language


Any MTA should be ale to relay mail. :)

my idea is that i recently encounter more and more email forms which do 
not allow me to use + addressing so my idea is to setup my own MTA 
which will redirect emails send to t...@registeruser.example.com to 
forexample registeru...@gmail.com


Postfix can easily be configured to do that for you.  I expect Exim can 
too though.


In the case of Postfix, you'd just set up a virtual(5) map to redirect 
the emails to their final destination.


I'd suggest you compare the configuration file formats of the different 
MTAs your operating system offers and pick the one you find most 
comfortable.


Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Re: Temporarily stop mail delivery

[Ralph Seichter]

On 25.12.2017 11:14, Black Sheep wrote:

> Is there a simple way to temporarily stop postfix delivering mail into
> the /var/vmail mail boxes [...]

The following method works (I'm not certain if reloading is even
required):

#!/bin/bash
# Temporarily disable local delivery
postconf -e defer_transports=local && postfix reload
[... Your backup operations here ...]
# Re-enable local delivery
postconf -e defer_transports='' && postfix reload

-Ralph

Re: Postfix vs Exim

[vonProteus]

my ultimate goal is to configure MTA in that way that i'm able to use it as
a mail relay station
sorry for my not fully technical and poor language
my idea is that i recently encounter more and more email forms which do not
allow me to use + addressing
so my idea is to setup my own MTA which will redirect emails send to
t...@registeruser.example.com to forexample registeru...@gmail.com

On Mon, Dec 25, 2017 at 10:04 AM, Marat Khalili  wrote:

> Flamebait question, but I happened to configure both (repository versions)
> recently, so here's one opinion. Both are useable, and used. Exim is sold
> as easier to configure, but IMO it doesn't deliver on this - probably
> simple config is just an impossible thing for universal SMTP MTA. On the
> other hand, Postfix has larger internet share and more resources on the web
> dedicated to it. Therefore I usually go for postfix (once you learned it,
> it's not that hard), and only use exim if there's no postfix in
> distribution repository.
> --
>
> With Best Regards,
> Marat Khalili
>

Re: Postfix vs Exim

[Philip Paeps]

On 2017-12-25 09:31:07 (+0100), vonProteus wrote:

With one is better and why do you think so?
I’m going to chose one and would like to know your opinion


Well ... you're asking on the Postfix mailing list.  Obviously people 
are going to answer Postfix. :)


To be honest, I never looked at Exim.  After a "robust" interaction with 
Sendmail in early 2000, someone suggested I look at Postfix.  I never 
looked back.


(Grepping through revision control logs of old configuration files, the 
earliest version I can find mentioned was "19991231-pl8" around 
mid-2000, which I apparently upgraded to "19991231-pl13" in early 2001.  
Version numbers didn't come along until a year or so after that :)  
Happy days!)


Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Temporarily stop mail delivery

[Black Sheep]

Is there a simple way to temporarily stop postfix delivering mail into the 
/var/vmail mail boxes, instead queueing them up? The purpose being to get a 
clean backup of /var/vmail without stopping receipt of mail from the internet. 
Then restart mail delivery so the queue is emptied into the appropriate local 
mail boxes?

Martin

Re: Postfix vs Exim

[Marat Khalili]

Flamebait question, but I happened to configure both (repository versions) 
recently, so here's one opinion. Both are useable, and used. Exim is sold as 
easier to configure, but IMO it doesn't deliver on this - probably simple 
config is just an impossible thing for universal SMTP MTA. On the other hand, 
Postfix has larger internet share and more resources on the web dedicated to 
it. Therefore I usually go for postfix (once you learned it, it's not that 
hard), and only use exim if there's no postfix in distribution repository.
-- 

With Best Regards,
Marat Khalili

Postfix vs Exim

[vonProteus]

With one is better and why do you think so?
I’m going to chose one and would like to know your opinion

regards
vonProteus