We're using a MySQL virtual table to deliver to Cyrus IMAP via LMTP. It
looks like postfix is lowercasing the unmatched address extension (after
the +) when adding it back to the result of the lookup.
Is there any way to prevent this from happening?
We're running Postfix 2.0.19.
Thanks.
-David
Postfix case folds the input before table lookup is done.
Systems that depend on case sensitive addresses are fragile.
Wietse
> David R Bosso:
>> Howdy,
>>
>> We're using a MySQL virtual table to deliver to Cyrus IMAP via LMTP. It
>> looks like postfix is lowercasing the unmatched address extension (after
>> the +) when adding it back to the result of the lookup.
>>
>> Is there any way to prevent this from happening?
>
> Postfix case folds the input before table lookup is done.
>
> Systems that depend on case sensitive addresses are fragile.
Thanks. In our case the address extension specifies a user mailbox and the
mailbox namespace is case sensitive. The current Postfix behavior imposes
a requirement that plus addressing can only be used to deliver to all
lowercased mailboxes. This is somewhat confusing to the end user, and
therefore not desirable.
Would you accept a patch to retain case on the extension part? I'm not
sure how hard it is, but I'm asking before I put any time into it.
Alternatively an option on whether to case fold the input would also be
useful.
-David
This should work for every address manipulation class that is
controlled by the propagate_unmatched_extensions configuration
parameter.
> Alternatively an option on whether to case fold the input would also be
> useful.
If case preserved extensions are introduced then certainly the
existing behavior needs to be available.
Wietse