On 03.12.2016 15:10, Bartosz Rudnicki wrote:
On 30.11.2016 19:30, Bartosz Rudnicki wrote:
On 2016-11-30 01:18, LaMont Jones wrote:
On Sat, Nov 26, 2016 at 01:06:26PM -0500, Scott Kitterman wrote:
On Saturday, November 26, 2016 06:42:13 PM Bartosz Rudnicki wrote:
Yes, there is a tab character after pcre.
I set "chroot" option to "n" for all services in the master.cf and
restarted postfix.
Now, during sending a message, the following messages filling up
the log
file:
Nov 26 18:11:45 Sirius postfix/cleanup[1723]: error: open
/etc/postfix/pcre/auth_policies: Permission denied
What are the permissions on /etc/postfix/pcre? That almost looks like
the postfix user is unable to access the directory.
Nov 26 18:11:45 Sirius postfix/cleanup[1723]: warning:
pcre:/etc/postfix/pcre/auth_policies is unavailable. open
/etc/postfix/pcre/auth_policies: Permission denied
Nov 26 18:11:45 Sirius postfix/cleanup[1723]: warning: 42B227212B6:
milter_header_checks map lookup problem -- message not accepted, try
again later
Although I set recursively 777 permissions for /etc/postfix/pcre/
directory, postfix can not reach my pcre map file.
Try 755 -- postfix is picky about world writable directories, iirc.
Did you use postmap [1] to update the map?
pcre maps do not need postmap compilation (nor does postmap accept such
requests.)
The next thing to do would be to add some -v options (3 or 4 of
them) to
the cleanup line in master.cf and see what it has to spew into the
logs.
FWIW, pcre maps seem to work just fine for me in 3.1.3-4.
lamont
First of all - I noticed that pcre complications appears only when
using "milter_header_checks"; After removing this option and
replacing it with "header_checks" and "mime_header_checks" -
everything seems to work properly.
So in order to reproduce the situation in another environment, the
milter application is needed, which has to append additional header
to the message.
I set the /etc/postfix/pcre directory permissions to 755 and repeated
attempts both for default master.cf file (default chroot settings)
and for modified master.cf file, where all commands have "chroot"
option set to NO.
Results are the same as before:
1) for default master.cf:
http://pastebin.com/raw/ukfF5Zui
2) for modified master.cf (no-chroot):
http://pastebin.com/raw/5CJZU8Ki
I've just figured out that postfix directory had not a execute
permission for others (711), so cleanup could not read the pcre map
file. Sorry for my oversight. Now, everything seems to work fine but
obviously only for the non-chrooted cleanup instance.
Interestingly the "header_checks" and "mime_header_checks" do not need
"x" permission on /etc/postfix/ directory when cleanup works without
chroot.
Due to inaccurate description of the reported issue which caused
misunderstanding, I intend to describe mentioned behaviors once again,
keeping in mind the specific conditions which MUST be satisfied in order
to recreate this bug.
By default, the cleanup process works chrooted inside postfix queue
directory. Maintaining this option untouched, I am able to set
additional "header_checks" or "mime_header_checks" functionality, by
adding corresponding options in the main.cf file. For this example I
used the pcre map type which requires additional package be installed
(postfix-pcre). After installation required package and indicate testing
pcre map file (which rejects every input string) in the "header_checks"
and "mime_header_checks" options, postfix reload is needed. In this case
everything works properly - received message via smtpd is catched by
cleanup process and respectively rejected.
The undesirable behavior appears ONLY, when the "milter_header_checks"
option is used. But for this, a milter application is needed which will
append additional header. I use OpenDKIM milter which inserts DKIM
signature to the message. After assign testing pcre map to the
"milter_header_checks" option and reload postfix, the following entries
fills up the mail log file causing tempfail in the SMTP conversation:
Dec 7 23:13:32 Sirius postfix/cleanup[2738]: warning: unsupported
dictionary type: pcre (/usr/lib/postfix/postfix-pcre.so.1.0.1: No such
file or directory)
Dec 7 23:13:32 Sirius postfix/cleanup[2738]: error: unsupported
dictionary type: pcre
I stress once again - this error *occurs ONLY* when
"milter_header_checks" option is used. This behavior*does not appear*
with the generic (mime_)header_checks!
A temporary solution is to set the cleanup process to work in the
non-chrooted mode. Aditionaly, but after that new obstacle has appeared
- Postfix comes with "o=" /etc/postfix/ directory permission, whereby
cleanup cannot reach the map file. "chmod o+x /etc/postfix/" should
cause to this workaround works properly.
Below, I put a step by step how to reproduce this bug:
*Postfix 3.1.3 from debian repository is needed.
*Any milter application which will write header to the message is needed
- I use OpenDKIM but OpenDMARC should be faster in configuration.
1. Make sure cleanup works with true chroot option in the master.cf file.
2. Set the "smtpd_milter" option respectively to your milter
configuration *and make sure that it really writes header when message
is received by smtpd*.
3. Install the postfix-pcre package (I did not try with other additional
map types)
4. Create a testing pcre map which will catch all cases:
/.*/ REJECT If you see this statement, the before-queue
header-checks work properly
and save it somewhere into /etc/postfix/ directory.
5. Set "milter_header_checks = pcre:/etc/postfix/pcre_test_file" option
in the main.cf file.
6. Reload postfix and try send a message through smtp.
I hope that it is now clearly explained and there will be no problem
with reproduction of this behavior.
Bartosz Rudnicki
