On 05/29/2013 11:26 AM, Simon B wrote:
On 28 May 2013 20:35, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
On Tue, May 28, 2013 at 08:22:56PM +0200, Simon B wrote:
On 28 May 2013 19:34, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote:
On Tue, May 28, 2013 at 07:25:02PM +0200, Simon B wrote:
On 28 May 2013 18:33, Benny Pedersen <m...@junc.eu> wrote:
Simon B skrev den 2013-05-28 17:33:
May 27 23:30:17 mail postfix/pipe[16721]: 57FF6C8C033:
to=<p...@example.co.uk>, relay=dovecot, delay=2, delays=2/0/0/0.05,
dsn=2.0.0, status=sent (delivered via dovecot se
rvice)
Virtual alias rewriting is performed by cleanup(8) per the override
flags passed from smtpd. Since this address was not rewritten,
and what changed recently is a newly disabled filter. Despite
reports to the contrary the problem is receive_override_options or
last resort a cleanup service with master.cf overrides for
virtual_alias_maps, ...
I know you're right. I just can't find it and I'd rather not rip things out
in trial and error.
I'll keep digging..
At the very least run "postfix reload", or even "stop/start" perhaps
master.cf does not match run-time reality. You can also briefly
run "cleanup -v" to see what cleanup is doing with rewriting and what
flags it receives from smtpd.
Okay, so now this is really odd. I had previously issued postfix
reload, but for safety, I now issued the stop/start after adding -v to
cleanup. No extra detail in the logs and the alias is still not
expanded.
That's not right, surely?
Indeed, that is not right; cleanup -v produces /dozens/ of log lines for
a single message.
Make sure you're editing the right configuration.
Replace the -v with something invalid, like -@, and reload.
If that does not complain, you're not editing the right config.
--
J.
