On 31 Jan 2015, at 21:10, LuKreme wrote:
On Jan 31, 2015, at 5:21 PM, Wietse Venema <wie...@porcupine.org>
wrote:
LuKreme:
On Jan 31, 2015, at 4:55 PM, LuKreme <krem...@kreme.com> wrote:
On Jan 31, 2015, at 4:23 PM, Wietse Venema <wie...@porcupine.org>
wrote:
LuKreme:
Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
to=<oq6+2nbq@*munged*.com>, orig_to=<oq6_2nbq@*munged*.com>,
relay=dovecot, delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1,
status=bounced (user unknown)
That will produce backscatter. Why did you accept an unknown
recipient?
I don?t know, that?s what I was trying to find.
Everything I have about queue ID E64DA50D3A1 in maillog was posted
in the original message.
Oh, wait, i think I just found it in an old pre map. Off to test.
Yes, the old PCRE map was the problem. IN trying to fix it, I went
to change the recipient_delimiter
$ postfix reload
postfix/postlog: fatal: bad string length 2 > 1: recipient_delimiter
= +_
postsuper: fatal: bad string length 2 > 1: recipient_delimiter = +_
mail /etc/postfix] $ postconf recipient_delimiter mail_version
recipient_delimiter = +_
mail_version = 2.11.3
No such problems here.
% bin/postconf mail_version recipient_delimiter
mail_version = 2.11.3
recipient_delimiter = +_
# bin/postsuper -v
# bin/postlog foo
postfix/postlog: foo
I suppose you have a Frankenstein Postfix installation, with some
parts coming from different bodies?
I wouldn’t think so unless postmaster did something very odd.
# postsuper -v
postsuper: name_mask: ipv4
postsuper: inet_addr_local: configured 2 IPv4 addresses
postsuper: queue: defer
postsuper: queue: bounce
postsuper: queue: maildrop
postsuper: queue: incoming
postsuper: queue: active
postsuper: queue: deferred
postsuper: queue: hold
postsuper: queue: flush
# postlog foo
postfix/postlog: foo
# postconf recipient_delimiter
recipient_delimiter = +_
# postfix reload
postfix/postlog: fatal: bad string length 2 > 1: recipient_delimiter =
+_
postsuper: fatal: bad string length 2 > 1: recipient_delimiter = +_
# ls -lsa /usr/sbin/post*
400 -rwxr-xr-x 1 root wheel 203012 Jan 25 12:21
/usr/sbin/postalias
192 -rwxr-xr-x 1 root wheel 97216 Jan 25 12:21
/usr/sbin/postcat
520 -rwxr-xr-x 1 root wheel 262156 Jan 25 12:21
/usr/sbin/postconf
328 -rwxr-sr-x 1 root maildrop 165092 Jan 25 12:21
/usr/sbin/postdrop
168 -rwxr-xr-x 1 root wheel 84360 Jan 25 12:21
/usr/sbin/postfix
184 -rwxr-xr-x 1 root wheel 92804 Jan 25 12:21
/usr/sbin/postkick
176 -rwxr-xr-x 1 root wheel 89604 Jan 25 12:21
/usr/sbin/postlock
168 -rwxr-xr-x 1 root wheel 84632 Jan 25 12:21
/usr/sbin/postlog
408 -rwxr-xr-x 1 root wheel 206036 Jan 25 12:21
/usr/sbin/postmap
192 -rwxr-xr-x 1 root wheel 97944 Jan 25 12:21
/usr/sbin/postmulti
408 -rwxr-sr-x 1 root maildrop 206532 Jan 25 12:21
/usr/sbin/postqueue
200 -rwxr-xr-x 1 root wheel 101720 Jan 25 12:21
/usr/sbin/postsuper
336 -rwxr-xr-x 1 root wheel 168984 Jan 25 12:21
/usr/sbin/posttls-finger
And yes, the 25th is when I installed postfix 2.11.3
Which doesn't mean you don't have some other Postfix binaries lurking...
e.g.:
# /usr/sbin/postlog foo
postfix/postlog: fatal: bad string length 2 > 1: recipient_delimiter =
-+
# postlog foo
postfix/postlog: foo
# which postlog
/opt/local/sbin/postlog
It is possible to get FrankenPostfix Syndrome in a variety of ways. It
seems clear from your command demos that whatever you are running as
"postfix" in an interactive shell is calling different (old) postlog and
postsuper binaries that differ from the ones you get from calling the
unqualified executable name in an interactive shell. That's odd but not
impossible. The postfix executable has a bunch of fixed paths hardcoded
into it at build time, which can cause trouble and WILL if you try to
move around a Postfix installation to somewhere it wasn't build for.
