Address extension case folding for aliases

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Address extension case folding for aliases

Fedor Piecka
Hello

I'm implementing a new feature in our mail system which uses address extensions for message delivery to user inbox subfolders.

I've found out that alias expansion folds case not only of user part of address (before +), but it also folds the address extension (after +).

I've setup a basic Postfix(3.3.1) configuration for the purpose of testing with the following settings:

local_recipient_maps =
mailbox_transport = smtp:127.0.0.1:2525
recipient_delimiter = +
propagate_unmatched_extensions = canonical,alias


Alias file contains a single line:
john.doe: doe


If I send 2 messages through SMTP, one addressed to "doe+CamelCase@testhostname", the other to "john.doe+CamelCase@testhostname", this is what happens:

postfix/smtp[17600]: 43D3D29F15: to=<doe+CamelCase@testhostname>, relay=127.0.0.1[127.0.0.1]:2525, delay=0.16, delays=0.02/0.02/0.07/0.05, dsn=2.0.0, status=sent (250 2.0.0 OK: queued as <[hidden email]>)
postfix/smtp[17600]: 952B929F15: to=<doe+camelcase@testhostname>, orig_to=<john.doe+CamelCase@testhostname>, relay=127.0.0.1[127.0.0.1]:2525, delay=0.1, delays=0.01/0/0.04/0.05, dsn=2.0.0, status=sent (250 2.0.0 OK: queued as <[hidden email]>)

The first one is delivered correctly into CamelCase mailbox and the other is delivered to the camelcase mailbox.

I think this is an undesired behavior as the handling of address extensions for aliased and non-aliased users is different. Aliased users cannot use uppercase letters in IMAP folder names if they want to allow direct delivery into them.

I've searched through the documentation for any explanation/solution. It isn't clear from the docs whether such a folding should be done. From virtual(5):

The   propagate_unmatched_extensions   parameter  controls  whether  an
       unmatched address extension (+foo) is propagated to the result of table
       lookup.
and:
       The search string is folded to lowercase before database lookup. As  of
       Postfix  2.3,  the search string is not case folded with database types
       such as regexp: or pcre: whose lookup fields can match both  upper  and
       lower case.

I would expect the "propagate_unmatched_extensions" option to work consistently and without case folding.

Do you have a different opinion?

Regards
Fedor
Reply | Threaded
Open this post in threaded view
|

Re: Address extension case folding for aliases

Fedor Piecka
Additional information. I've cited the man page of virtual but in the
test I've mentioned, I've used local delivery. In local(5), the
information is more interesting but still no clear explanation:

CASE FOLDING
       All delivery decisions are made using the bare recipient name (i.e. the
       address  localpart),  folded  to  lower  case.   See also under ADDRESS
       EXTENSION below for a few exceptions.


There is no explicit information on case folding in ADDRESS EXTENSION section...

Additionally, the man page says "all delivery decisions", but it
doesn't say anything about rewriting the envelope recipient address
with a case folded equivalent.

Regards
Fedor

2018-10-18 21:23 GMT+02:00, Fedor Piecka <[hidden email]>:

> Hello
>
> I'm implementing a new feature in our mail system which uses address
> extensions for message delivery to user inbox subfolders.
>
> I've found out that alias expansion folds case not only of user part of
> address (before +), but it also folds the address extension (after +).
>
> I've setup a basic Postfix(3.3.1) configuration for the purpose of testing
> with the following settings:
>
> local_recipient_maps =
> mailbox_transport = smtp:127.0.0.1:2525
> recipient_delimiter = +
> propagate_unmatched_extensions = canonical,alias
>
>
> Alias file contains a single line:
> john.doe: doe
>
>
> If I send 2 messages through SMTP, one addressed to
> "doe+CamelCase@testhostname", the other to
> "john.doe+CamelCase@testhostname",
> this is what happens:
>
> postfix/smtp[17600]: 43D3D29F15: to=<doe+CamelCase@testhostname>,
> relay=127.0.0.1[127.0.0.1]:2525, delay=0.16, delays=0.02/0.02/0.07/0.05,
> dsn=2.0.0, status=sent (250 2.0.0 OK: queued as
> <[hidden email]>)
> postfix/smtp[17600]: 952B929F15: to=<doe+camelcase@testhostname>,
> orig_to=<john.doe+CamelCase@testhostname>, relay=127.0.0.1[127.0.0.1]:2525,
> delay=0.1, delays=0.01/0/0.04/0.05, dsn=2.0.0, status=sent (250 2.0.0 OK:
> queued as <[hidden email]>)
>
> The first one is delivered correctly into CamelCase mailbox and the other
> is delivered to the camelcase mailbox.
>
> I think this is an undesired behavior as the handling of address extensions
> for aliased and non-aliased users is different. Aliased users cannot use
> uppercase letters in IMAP folder names if they want to allow direct
> delivery into them.
>
> I've searched through the documentation for any explanation/solution. It
> isn't clear from the docs whether such a folding should be done. From
> virtual(5):
>
> The   *propagate_unmatched_extensions
> <http://www.postfix.org/postconf.5.html#propagate_unmatched_extensions>*
>   parameter  controls  whether  an
>        unmatched address extension (*+foo*) is propagated to the result of
> table
>        lookup.
>
> and:
>
>        The search string is folded to lowercase before database lookup. As
> of
>        Postfix  2.3,  the search string is not case folded with database
> types
>        such as regexp <http://www.postfix.org/regexp_table.5.html>: or
> pcre <http://www.postfix.org/pcre_table.5.html>: whose lookup fields
> can match both  upper  and
>        lower case.
>
>
> I would expect the "propagate_unmatched_extensions" option to work
> consistently and without case folding.
>
> Do you have a different opinion?
>
> Regards
> Fedor
>
Reply | Threaded
Open this post in threaded view
|

Re: Address extension case folding for aliases

Wietse Venema
Mail that is aliases by alias_maps is 'forwarded' as in: written
to a new queue file and reprocessed by the local delivery agent.
It is possible that the original case is lost in this 'forwarding'
code path. I'll look into this when I have time.

        Wietse