$EXTENSION always empty?

Xavier Mertens

unread,

May 11, 2022, 1:48:30 AM5/11/22

to

Hello,

New comer on this list and I hope to find some help...
I'm trying to configure my Postfix to use user+flag@domain addresses.
A new separator has been configured, mail is accepted but $EXTENSION remains always empty. I'm using procmail like this:

mailbox_command = /usr/bin/procmail -a "$EXTENSION"

In my .procmailrc, I've:

EXT=$1

But, no luck! Always empty variable! Did I miss something? Tx!

Bob Nichols

unread,

May 11, 2022, 5:56:44 AM5/11/22

to

On 2022-05-10 Tue 22:48:28 -0700, Xavier Mertens wrote:
> I'm trying to configure my Postfix to use user+flag@domain addresses.
> A new separator has been configured,

What is the output of
postconf recipient_delimiter
?

--
Bob Nichols
(for e-mail remove .invalid)

Xavier Mertens

unread,

May 11, 2022, 8:53:06 AM5/11/22

to

Here we go:

# postconf recipient_delimiter
recipient_delimiter = +

Nothing exotic :)

/x

Bob Nichols

unread,

May 11, 2022, 3:56:09 PM5/11/22

to

On 2022-05-11 Wed 05:53:04 -0700, Xavier Mertens wrote:
> # postconf recipient_delimiter
> recipient_delimiter = +

Okay, that's fine.

My next guess is that Postfix is rewriting the sender address before
passing the message on to procmail. Do you have an example of the log
messages for such a mail? Ideally from both Postfix and Procmail for the
same message. (Feel free to obfuscate any host names or IP addresses, so
long as the form of the email address is still visible.)

Bob Nichols

unread,

May 11, 2022, 4:06:28 PM5/11/22

to

On 2022-05-11 Wed 20:56:03 +0100, Bob Nichols wrote:
> My next guess is that Postfix is rewriting the sender address ...
Oops! that should of course read "rewriting the recipient address".

Xavier Mertens

unread,

May 11, 2022, 5:17:51 PM5/11/22

to

Here is an example:

May 10 22:32:56 marge postfix/local[27432]: 5A55027C0D3B: to=<xav...@domain.tld>, orig_to=<xavie...@domain.tld>, relay=local, delay=1.9, delays=1.9/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION" -a "$EXTENSION")

It seems to be what you suggested if I interpret correctly the "to" and "orig_to"...

/x

Bob Nichols

unread,

May 11, 2022, 9:50:06 PM5/11/22

to

On 2022-05-11 Wed 14:17:50 -0700, Xavier Mertens wrote:
> May 10 22:32:56 marge postfix/local[27432]: 5A55027C0D3B:
> to=<xav...@domain.tld>, orig_to=<xavie...@domain.tld>,
> relay=local, delay=1.9, delays=1.9/0.01/0/0.01, dsn=2.0.0,
> status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION"
> -a "$EXTENSION")
>
> It seems to be what you suggested if I interpret correctly the "to"
> and "orig_to"...

Yes, it looks like that is behind the problem. Do you have any .forward
(or .forward+foo) files in place for this recipient? Or any matching
entries in your alias map? If so, could you temporarily remove/comment
them, and then see what Procmail sees?

Xavier Mertens

unread,

May 12, 2022, 7:14:24 AM5/12/22

to

No .forward but I'm using a virtual table:

xav...@domain.tld. xavier

I also have an alias in /etc/aliases:

xavier: xav...@domain.tld

Bob Nichols

unread,

May 12, 2022, 9:37:13 AM5/12/22

to

On 2022-05-12 Thu 04:14:22 -0700, Xavier Mertens wrote:
> No .forward but I'm using a virtual table:
>
> xav...@domain.tld. xavier

That should be fine, so long as the output of
postconf propagate_unmatched_extensions
contains "virtual" (which is the default).

> I also have an alias in /etc/aliases:
>
> xavier: xav...@domain.tld

I think that that alias is the culprit, though I don't understand what
it is intended to achieve. Is domain.tld here the same domain as that in
the virtual table above?

Xavier Mertens

unread,

May 13, 2022, 9:34:48 AM5/13/22

to

I removed the line from /etc/aliases (followed by a "newalias"), tested again and... it worked!
Tx for your help!

Bob Nichols

unread,

May 13, 2022, 12:51:53 PM5/13/22

to

On 2022-05-13 Fri 06:34:47 -0700, Xavier Mertens wrote:
> I removed the line from /etc/aliases (followed by a "newalias"), tested again and... it worked!
> Tx for your help!
>

That's good news! (and on Friday 13th, no less)
I'm glad if my suggestions helped.