I have the following header_checks in place on Postfix
/^Received:/ IGNORE
/^X-Originating-IP:/ IGNORE
/^X-Mailer:/ IGNORE
/Message-Id:s+<(.*?)@www.mainserver.com>/ REPLACE Message-Id: <$1@www.domain.com>
/X-Mailer-LID:/ IGNORE
/^MIME-Version:/i PREPEND Precedence: bulk
/X-Mailer-RecptId:/ IGNORE
/X-Mailer-SID:/ IGNORE
/X-Mailer-Sent-By:/ IGNORE
/List-Unsubscribe:/ IGNORE
Once I activate them in postfix/main.cf (after running postmap /etc/postfix/header_checks) postfix stops working. When I attempt to send an email I get the following error log
Jun 20 03:19:26 mail postfix/pickup[6813]: F37593F946: uid=0 from=<root@domain.com>
Jun 20 03:19:26 mail postfix/cleanup[6819]: warning: pcre:/etc/postfix/header_checks is unavailable. unsupported dictionary type: pcre
Jun 20 03:19:26 mail postfix/cleanup[6819]: warning: pcre:/etc/postfix/header_checks lookup error for "Received: by mail.domain.com (Postfix, from userid 0)??id F37593F946; Thu, 20 Jun 2019 03:19:26 +0200"
Jun 20 03:19:26 mail postfix/cleanup[6819]: warning: F37593F946: header_checks map lookup problem -- message not accepted, try again later
Jun 20 03:19:26 mail postfix/pickup[6813]: warning: maildrop/F27653F945: error writing F37593F946: queue file write error
Jun 20 03:19:27 mail postfix/pickup[6813]: F42373F946: uid=0 from=<root@domain.com>
Jun 20 03:19:27 mail postfix/cleanup[6819]: warning: pcre:/etc/postfix/header_checks is unavailable. unsupported dictionary type: pcre
Jun 20 03:19:27 mail postfix/cleanup[6819]: warning: pcre:/etc/postfix/header_checks lookup error for "Received: by mail.domain.com (Postfix, from userid 0)??id F42373F946; Thu, 20 Jun 2019 03:12:51 +0200"
Jun 20 03:19:27 mail postfix/cleanup[6819]: warning: F42373F946: header_checks map lookup problem -- message not accepted, try again later
Jun 20 03:19:27 mail postfix/pickup[6813]: warning: maildrop/2C3F23F172: error writing F42373F946: queue file write error
Jun 20 03:19:27 mail postfix/pickup[6813]: 00EE13F946: uid=0 from=<root@domain.com>
Jun 20 03:19:27 mail postfix/cleanup[6819]: warning: pcre:/etc/postfix/header_checks is unavailable. unsupported dictionary type: pcre
Jun 20 03:19:27 mail postfix/cleanup[6819]: warning: pcre:/etc/postfix/header_checks lookup error for "Received: by mail.domain.com (Postfix, from userid 0)??id 00EE13F946; Thu, 20 Jun 2019 03:13:36 +0200"
Jun 20 03:19:27 mail postfix/cleanup[6819]: warning: 00EE13F946: header_checks map lookup problem -- message not accepted, try again later
Jun 20 03:19:27 mail postfix/pickup[6813]: warning: maildrop/924363F173: error writing 00EE13F946: queue file write error
What is causing this? I believe it works on my old CentOS 6 installation but I am having problems with my Ubuntu 18.04 installation.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
ferllings opened this issue
Feb 28, 2020
· 16 comments
Comments
Hello,
Still on my mailu fresh install, I have an error when trying to send email from roundcube:
Roundcube error is
SMTP Error: [451] 4.3.0 Error: queue file write error
And when I look at the postix logs, I found:
postfix/smtpd[528839]: connect from 10-42-0-101.mailu-front.default.svc.cluster.local[10.42.0.101]
postfix/cleanup[528842]: error: unsupported dictionary type: pcre
postfix/smtpd[528839]: 31DB96A000D: client=10-42-0-100.mailu-roundcube.default.svc.cluster.local[10.42.0.100], sasl_method=XCLIENT, sasl_username=contact@id
postfix/cleanup[528842]: warning: pcre:/etc/postfix/outclean_header_filter.cf is unavailable. unsupported dictionary type: pcre
postfix/cleanup[528842]: warning: pcre:/etc/postfix/outclean_header_filter.cf lookup error for "Received: from mail.xxxx.net
postfix/cleanup[528842]: warning: 31DB96A000D: header_checks map lookup problem -- message not accepted, try again later
postfix/cleanup[528842]: 425956A000D: message-id=<20200228101927.425956A000D@mail.xxx.net>
postfix/qmgr[174]: 425956A000D: from=<double-bounce@mail.xxx.net>, size=1147, nrcpt=1 (queue active)
postfix/smtpd[528839]: disconnect from 10-42-0-100.mailu-roundcube.default.svc.cluster.local[10.42.0.100] ehlo=2 xclient=0/1 mail=1 rcpt=1 data=0/1 rset=0/1
postfix/lmtp[528843]: 425956A000D: to=<postmaster@xxx.net>, orig_to=<postmaster>, relay=mailu-dovecot[10.43.99.120]:2525, delay=0.22, delays=0.06/0.08/
postfix/bounce[528844]: warning: 425956A000D: undeliverable postmaster notification discarded
postfix/qmgr[174]: 425956A000D: removed
postfix/smtpd[527942]: connect from localhost[127.0.0.1]
postfix/smtpd[527942]: disconnect from localhost[127.0.0.1] quit=1 commands=1
postfix/smtpd[527942]: connect from localhost[127.0.0.1]
Thanks for your help
I can’t figure out the problem: the package are installed.
> apk list | grep pcre
WARNING: Ignoring APKINDEX.00740ba1.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.d8b2a6f4.tar.gz: No such file or directory
pcre-8.43-r0 x86_64 {pcre} (BSD-3-Clause) [installed]
postfix-pcre-3.4.7-r0 x86_64 {postfix} (IPL-1.0 EPL-2.0) [installed]
pcre2-10.33-r0 x86_64 {pcre2} (BSD-3-Clause) [installed]
No idea why it happened.
I simply restarted the postfix container and the error is gone.
I reopen this issue as it comes back after few hours until I restart the postfix instance.
I noticed the module isn’t loaded in postfix:
# postconf -m
btree
cidr
environ
fail
hash
inline
internal
memcache
pipemap
proxy
randmap
regexp
socketmap
static
tcp
texthash
unionmap
unix
I just stumbled on this, too.
Helped not restarting, but recreating the container.
For me it happened after upgrade from 1.5 to 1.7 — but there was nothing in configuration overrides or otherwise modified.
Some updates — even with container recreation after some time pcre is again missing from postconf -m entries.
Also noticed that for some reason — after this if you happen to restart the container post-install complains that it cannot find file /etc/postfix/postfix-files file. While if the container is recreated then the file exists.
Yes, that’s exactly it.
I scheduled an email send every morning, to monitor the server.
It works for few days, then the error comes back with no specific reason.
Something cleans out /etc/postfix directory from configs. When the condition kicks in then contents of the folder is like this:
-rw-r--r-- 1 root root 3250 Apr 18 17:04 main.cf
-rw-r--r-- 1 root root 1927 Apr 18 17:04 master.cf
-rw-r--r-- 1 root root 923 Apr 18 17:04 outclean_header_filter.cf
While for the fresh container it’s like this:
-rw-r--r-- 1 root root 21535 Oct 2 2019 access
-rw-r--r-- 1 root root 10519 Oct 2 2019 aliases
-rw-r--r-- 1 root root 13194 Oct 2 2019 canonical
-rw-r--r-- 1 root root 60 Oct 2 2019 dynamicmaps.cf
drwxr-xr-x 2 root root 4096 Apr 11 18:36 dynamicmaps.cf.d
-rw-r--r-- 1 root root 10221 Oct 2 2019 generic
-rw-r--r-- 1 root root 23802 Oct 2 2019 header_checks
-rw-r--r-- 1 root root 3250 Apr 20 06:58 main.cf
-rw-r--r-- 1 root root 26857 Oct 2 2019 main.cf.proto
-rw-r--r-- 1 root root 1927 Apr 20 06:58 master.cf
-rw-r--r-- 1 root root 6328 Oct 2 2019 master.cf.proto
-rw-r--r-- 1 root root 923 Apr 20 06:58 outclean_header_filter.cf
-rw-r--r-- 1 root root 17070 Oct 2 2019 postfix-files
drwxr-xr-x 2 root root 4096 Apr 11 18:36 postfix-files.d
-rw-r--r-- 1 root root 6929 Oct 2 2019 relocated
-rw-r--r-- 1 root root 12666 Oct 2 2019 transport
-rw-r--r-- 1 root root 13963 Oct 2 2019 virtual
And as well as @ferllings mentioned — Postfix misses pcre module.
This error becoming really annoying because we use Mailu on production system. I tried to downgrade just SMTP container to version 1.6 — but it didn’t helped. After certain time — got the same situation as described above.
Any ideas @kaiyou ?
@ferllings nope.
Did a couple of tries with pulling fresh images, removing everything (including pruning volumes), but no luck. ~24h and again /etc/postfix is empty, postconf -m lacks pcre module and I’m getting SMTP Error: [451] 4.3.0 Error: queue file write error.
Also googled around — but unfortunately can’t find cause for missing pcre module.
Now setting up some monitoring for the containers to see what exactly goes wrong.
Still no updates, but I solved my problem by creating a crontab script that checks /etc/postfix directory in smtp container every 5 minutes. If it has less files than default — it sends me an email, so then I know that something is wrong and I can then restart the smtp container.
Also I’ve a sneaking suspicion that it’s not the smtp container causing problems, but some other — because if map /etc/postfix to host directory then SMTP isn’t crashing, but instead there is some weird behaviour for spam, admin and imap containers. Unfortunately due to production system — I had no time to investigate more…
Hi There,
The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.
To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.
In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the 😃 icon to the top-right).
- 👍️ if you need this to be able to use Mailu. Ideally, you’d also be able to test this on your installation, and provide feedback …
- 🎉 if you find it a nice bonus, but no deal-breaker
- 🚀 if you want to work on it yourself!
We want to keep this voting open for 2 weeks from now, so please help out!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has not seen activity since as it has become stale. It will now be automatically closed. Please note that this is an automatic action, and not meant in any offensive way.
-
uberkuhl
- Posts: 3
- Joined: 2019/12/08 03:50:33
Postfix — PCRE
I am presently working on migrating from CentOS 7 to CentOS 8. Under CentOS 7, I had check_sender_access pcre:/etc/postfix/reject_domains.
In my logs, I see «error: unsupported dictionary type: pcre». It seems like CentOS 8 is missing the postfix-pcre library.
RHEL 8.0 documentation seems to suggest there is postfix-pcre package (ref. https://access.redhat.com/documentation … el_8/index). Is this not available under CentOS 8?
Thanks for reading.
-
uberkuhl
- Posts: 3
- Joined: 2019/12/08 03:50:33
Re: Postfix — PCRE also no postgrey
Post
by uberkuhl » 2019/12/08 12:40:58
I was able to convert the PCRE to REGEXP, so have a work-around to move forward at least.
It seems postgrey is also not yet available via EPEL.
-
u297b
- Posts: 13
- Joined: 2019/10/06 17:04:29
Re: Postfix — PCRE
Post
by u297b » 2019/12/10 13:21:26
Personally, these types of issues are why I am moving many of my services over to podman containers.
Its a bit of front-end work to get everything in the container working, but once that work is done you are effectively protected against host OS issues in the future. For me, I’m spinning up lots of my container images using debian:buster-slim image (although you certainly could use centos7).
If you want to proceed in this route, my advice is to try to separate the various pieces of a complete mail server into its various sub-services and create a container for each (ie. postfix, dovecot, postgresql, roundcube, etc) then place all of these into same ‘pod’ so they can all share networking.
Once you get everything working it becomes trivial to move servers in the future.
-
uberkuhl
- Posts: 3
- Joined: 2019/12/08 03:50:33
Re: Postfix — PCRE
Post
by uberkuhl » 2019/12/10 15:39:45
Thanks for suggesting an alternative approach. I am not familiar with podman containers, so will do some reading.
I must admit that I find the process of migrating and configuring a series of services (autofs, postfix, dovecot, postgrey, apache, nextcloud, ssl certs, php, mariadb, etc.) a bit tedious.
Thanks again for the tip. I will check it out.
-
KernelOops
- Posts: 428
- Joined: 2013/12/18 15:04:03
- Location: xfs file system
Re: Postfix — PCRE
Post
by KernelOops » 2019/12/17 16:05:25
For some weird reason, someone in his infinite wisdom, decided to remove PCRE from RHEL 8 and thus from CentOS 8.
A temporary solution, is to convert your postfix configuration to use REGEXP lookups, which work in the same way but are slightly slower.
I’m managing many large email servers, running CentOS 7 at the moment and I am testing CentOS 8 as a future upgrade, but so far there are a lot of missing EPEL packages 
hopefully 8.1 will be better prepared.
—
R.I.P. CentOS 
—
-
maamo
- Posts: 1
- Joined: 2020/02/18 04:50:00
Re: Postfix — PCRE
Post
by maamo » 2020/02/18 04:59:32
There is a postfix-pcre when you build the SRPM package.
I don’t know why it is not in the standard repository, but … 
—-
dnf update -y
dnf group install ‘Development Tools’ -y
dnf install dnf-utils cyrus-sasl-devel libdb-devel openldap-devel
pcre-devel sqlite-devel mariadb-connector-c-devel libicu-devel
libnsl2-devel postgresql-devel tinycdb-devel —enablerepo=PowerTools -y
cd /tmp
curl -LO http://vault.centos.org/8.1.1911/BaseOS … l8.src.rpm
rpmbuild —rebuild /tmp/postfix-3.3.1-9.el8.src.rpm
rpm -ivh /root/rpmbuild/RPMS/x86_64/postfix-pcre-3.3.1-9.el8.x86_64.rpm
—-
# ls -1 /root/rpmbuild/RPMS/x86_64/
postfix-3.3.1-9.el8.x86_64.rpm
postfix-cdb-3.3.1-9.el8.x86_64.rpm
postfix-cdb-debuginfo-3.3.1-9.el8.x86_64.rpm
postfix-debuginfo-3.3.1-9.el8.x86_64.rpm
postfix-debugsource-3.3.1-9.el8.x86_64.rpm
postfix-ldap-3.3.1-9.el8.x86_64.rpm
postfix-ldap-debuginfo-3.3.1-9.el8.x86_64.rpm
postfix-mysql-3.3.1-9.el8.x86_64.rpm
postfix-mysql-debuginfo-3.3.1-9.el8.x86_64.rpm
postfix-pcre-3.3.1-9.el8.x86_64.rpm
postfix-pcre-debuginfo-3.3.1-9.el8.x86_64.rpm
postfix-perl-scripts-3.3.1-9.el8.x86_64.rpm
postfix-pgsql-3.3.1-9.el8.x86_64.rpm
postfix-pgsql-debuginfo-3.3.1-9.el8.x86_64.rpm
postfix-sqlite-3.3.1-9.el8.x86_64.rpm
postfix-sqlite-debuginfo-3.3.1-9.el8.x86_64.rpm
—-
# postconf -m
btree
cidr
environ
fail
hash
inline
internal
memcache
nis
pcre
pipemap
proxy
randmap
regexp
socketmap
static
tcp
texthash
unionmap
unix
-
TrevorH
- Site Admin
- Posts: 32527
- Joined: 2009/09/24 10:40:56
- Location: Brighton, UK
Re: Postfix — PCRE
Post
by TrevorH » 2020/02/18 12:06:37
https://bugzilla.redhat.com/show_bug.cgi?id=1745321 says
Fixed In Version: postfix-3.3.1-10.el8
Doc Type: Bug Fix
Doc Text: .PCRE, CDB, and SQLite can now be used with PostfixIn RHEL 8, the `postfix` package has been split into multiple subpackages, each subpackage providing a plug-in for a specific database. Previously, RPM packages containing the `postfix-pcre`, `postfix-cdb`, and `postfix-sqlite` plug-ins were not distributed. Consequently, databases with these plug-ins could not be used with Postfix. This update adds RPM packages containing the PCRE, CDB, and SQLite plug-ins to the AppStream repository. As a result, these plug-ins can be used after the appropriate RPM package is installed.
So according to that, it’s in the next, currently unreleased version of the package (current is 3.3.1-9, fix in 3.3.1-10). No idea if that will be released as an errata or if it willneed to wait for 8.2.
Motivation: I’m changing my ticketing system so that messages with a friendlier subject line. Instead of ‘Subject: [SNAFU #1] summary’, I’ll change it to use ‘Subject: [HELPDESK #1] summary’.
Another colleague suggested we use procmail. As unixgeeks.org says:
Is procmail right for me?
Procmail is a serious unix hack. On the other hand, it does a pretty good job.
(http://unixgeeks.org/security/newbie/unix/procmail/procmail.html)
I think we can do better than a serious Unix hack. I think Postfix can handle this.
How to do it?
First, I created a test environment: two Debian 9 virtual machines:
- foo.osric.net
- bar.osric.net
I’m not going to add DNS entries, though, so I’ll be relying on their IP addresses on my internal network:
- 192.168.0.18
- 192.168.0.19
I installed postfix and mutt on each:
# apt-get install postfix muttAs an initial test, I tried to send a message from one machine to the other:
# sendmail root@192.168.0.18 < test.emlBut this resulted in an error from the mailer-daemon:
<root@192.168.0.18>: bad address syntaxThe solution? Enclose the IP address in square brackets:
# sendmail root@[192.168.0.18] < test.eml(Thanks to Is there a way to send an email to an IP address directly?, which I believe is the first time I have ever seen anything useful on the Quora web site.)
The two test systems can send messages to each other. Great!
Now, to change the subject line. A ServerFault post, postfix header_checks to rename email subject, looked like exactly what I was looking for (and a similar scenario motivated that question).
Following the answer there, I added the following to /etc/postfix/main.cf:
header_checks = pcre:/etc/postfix/header_checks.pcreAnd I created /etc/postfix/header_checks.pcre, containing the following:
/^Subject: [SNAFU #(d+)](.*)$/ REPLACE Subject: [HELPDESK #$1]$2Don’t forget to reload Postfix, required by just about any Postfix change:
# postfix reloadI sent a test message from bar to foo, and an error message arrived in root’s mailbox on foo:
Subject: Postfix SMTP server: errors from bar.osric.net[192.168.0.19]I checked the logs at /var/log/mail.log and found the following:
Jul 8 16:47:29 foo postfix/cleanup[10927]: error: unsupported dictionary type: pcreI reproduced this problem using postmap:
# postmap -q 'Subject: [SNAFU #1]' pcre:/etc/postfix/header_checks.pcre
postmap: fatal: unsupported dictionary type: pcreI changed the filename (not strictly necessary, but good for my sanity) and tried regexp instead:
# postmap -q 'Subject: [SNAFU #1]' regexp:/etc/postfix/header_checks.regexpThis produced no output, no error message, and a return code of 1. Why didn’t it match?
It turned out I needed to modify the regular expression, since d is a Perl-ism:
/^Subject: [SNAFU #([0-9]+)](.*)$/ REPLACE Subject: [HELPDESK #$1]$2(Using [[:digit:]] instead of [0-9] would also work.)
I ran a couple successful tests using postmap:
# postmap -q 'Subject: [SNAFU #1]' regexp:/etc/postfix/header_checks.regexp
REPLACE Subject: [HELPDESK #1]
~# postmap -q 'Subject: [SNAFU #1] more text' regexp:/etc/postfix/header_checks.regexp
REPLACE Subject: [HELPDESK #1] more textNow to test an actual e-mail message.
First, I updated /etc/postfix/main.cf to point to the updated filename with the corresponding dictionary type:
header_checks = regexp:/etc/postfix/header_checks.regexpDon’t forget:
# postfix reloadI tested it from bar.osric.net (192.168.0.19), using the following file, test.eml:
Subject: [SNAFU #1] test message
This is a test.# sendmail root@[192.168.0.18] < test.emlIt appeared in root’s inbox on foo.osric.net (192.168.0.18) with the updated subject as expected:
Date: Sun, 8 Jul 2018 17:03:56 -0500 (CDT)
From: root <root@bar.osric.net>
Subject: [HELPDESK #1] test message
This is a test.I sent another message with a different subject line just to confirm it was unchanged by the header_check.
Other useful resources:
- Postfix documentation: header_checks
- Postfix documentation: postmap
- Postfix documenation: regexp table
После обновления с ubuntu 15.10 до 16.04 перестал работать postfix
postfix/proxymap[35158]: warning: mysql:/etc/postfix/mysql/sender_bcc_maps_user.cf is unavailable. unsupported dictionary type: mysql
postfix/cleanup[35159]: warning: proxy:mysql:/etc/postfix/mysql/sender_bcc_maps_user.cf lookup error for «user@domain.com»
postfix/cleanup[35159]: warning: D79B580DBC: sender_bcc_maps map lookup problem — message not accepted, try again later
в mail.err
postfix/cleanup[35159]: error: unsupported dictionary type: pcre postfix/proxymap[35158]: error: unsupported dictionary type: mysql
postconf -m
pcre и mysql есть.
Переустановка postfix-mysql и postfix не помогают.
postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_min_user = no
allow_percent_hack = no
biff = no
body_checks = pcre:/etc/postfix/body_checks.pcre
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix/sbin
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
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
enable_original_recipient = no
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
lmtp_tls_mandatory_protocols = !SSLv2 !SSLv3
lmtp_tls_protocols = !SSLv2 !SSLv3
mail_owner = postfix
mailbox_command = /usr/lib/dovecot/deliver
mailq_path = /usr/bin/mailq
message_size_limit = 15728640
mydestination = $myhostname, localhost, x-fil.es, localhost.localdomain
mydomain =domain.com
myhostname = domain.com
mynetworks = 127.0.0.1, 192.168.1.0/24
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map = texthash:/etc/postfix/postscreen_dnsbl_reply
postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2 bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.s orbs.net psbl.surriel.com bl.mailspike.net swl.spamhaus.org*-4 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.o rg=127.[0..255].[0..255].1*-3 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_whitelist_threshold = -2
postscreen_greet_action = enforce
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_canonica l_maps $smtp_generic_maps $smtpd_sender_login_maps $transport_maps $virtual_alias_domains $virtual_alias_maps $virtua l_mailbox_domains $virtual_mailbox_maps $smtpd_sender_restrictions
queue_directory = /var/spool/postfix
recipient_bcc_maps = proxy:mysql:/etc/postfix/mysql/recipient_bcc_maps_user.cf proxy:mysql:/etc/postfix/mysql/recipie nt_bcc_maps_domain.cf
recipient_delimiter = +
relay_domains = $mydestination proxy:mysql:/etc/postfix/mysql/relay_domains.cf
relayhost = relay.lipetsk.ru:25
sender_bcc_maps = proxy:mysql:/etc/postfix/mysql/sender_bcc_maps_user.cf proxy:mysql:/etc/postfix/mysql/sender_bcc_ma ps_domain.cf
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix/lib
smtp-amavis_destination_recipient_limit = 1
smtp_tls_CAfile = $smtpd_tls_CAfile
smtp_tls_loglevel = 0
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = !SSLv2 !SSLv3
smtp_tls_security_level = may
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:7777
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_helo_hostname reject_invalid_he lo_hostname check_helo_access pcre:/etc/postfix/helo_access.pcre
smtpd_recipient_restrictions = reject_unknown_recipient_domain reject_non_fqdn_recipient reject_unlisted_recipient ch eck_policy_service inet:127.0.0.1:7777 permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_reject_unlisted_recipient = yes
smtpd_reject_unlisted_sender = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql/sender_login_maps.cf
smtpd_sender_restrictions = reject_unknown_sender_domain reject_non_fqdn_sender reject_unlisted_sender permit_mynetwo rks reject_sender_login_mismatch permit_sasl_authenticated check_sender_access pcre:/etc/postfix/sender_access.pcre
smtpd_tls_CAfile = /etc/ssl/certs/iRedMail.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt
smtpd_tls_dh1024_param_file = /etc/ssl/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-S HA, KRB5-DE5, CBC3-SHA
smtpd_tls_key_file = /etc/ssl/private/iRedMail.key
smtpd_tls_loglevel = 0
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_security_level = may
swap_bangpath = no
tls_random_source = dev:/dev/urandom
transport_maps = proxy:mysql:/etc/postfix/mysql/transport_maps_user.cf proxy:mysql:/etc/postfix/mysql/transport_maps_ domain.cf
unknown_local_recipient_reject_code = 550
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf proxy:mysql:/etc/postfix/mysql/domain_alias _maps.cf proxy:mysql:/etc/postfix/mysql/catchall_maps.cf proxy:mysql:/etc/postfix/mysql/domain_alias_catchall_maps.cf
virtual_gid_maps = static:2000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
virtual_minimum_uid = 2000
virtual_transport = dovecot
virtual_uid_maps = static:2000