Postfix vs Exim
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
Re: Postfix vs Exim
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
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
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
Re: Postfix vs Exim
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: Temporarily stop mail delivery
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
[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
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: 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? /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: Postfix vs Exim
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
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 usersSubject: 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
> 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
> 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: 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} 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
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: policyd-spf tip
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
migrating 2.1 to 3.x, what else is needed ?
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 dbl.spamhaus
TLS library problem: error:140760FC:SSL routines, is it a problem ?
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
Re: policyd-spf tip
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
Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?
> 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: TLS library problem: error:140760FC:SSL routines, is it a problem ?
>> 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 unknow
Re: TLS library problem: error:140760FC:SSL routines, is it a problem ?
>> 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 ?
> 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 ?
> 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: policyd-spf tip
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 ?
>> 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 =