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? I even tried adding an empty receive_override_options to the smtp line before the stop/start. Simon
