/dev/rob0:
> %x When the input key is an address of the form
> user+extension@domain, %x is replaced by the SQL
> quoted recipient_delimiter and extension of the
> local part of the address. Otherwise, %x is
> empty. If the localpart is empty, the query is
> suppressed and returns no results.
I agree that address extensions are toxic waste, under control by
random senders on the internet, so deriving file names from
sender-chosen data has to be done with care, if it is done at all.
But why is SQL quoting the appropriate solution?
If I were to derive file names from sender-controlled data (which
I think is not a good idea), then first of all I would neutralize
the '/' character (to prevent ../../.. tricks). Then, I'd censor
out all control characters, all punctuation characters and all
non-ASCII characters. I would also put a conservative limit on the
total length of the sender-controlled portion of a file name.
Absent a mechanism that restricts strings to known-good values (in
the way that address localparts and domain names are restricted),
I'd recommend against deriving file names from sender-specified
data.
Wietse
> and also as a result format. Among other amazing uses, this would
> enable automatic sorting of virtual(8) mail to subfolders based on
> extension:
>
> query = select (coalesce(path, '%d/%u/%x/') from VMailboxes ...
> where localpart || '%x' || '@' || domain is '%s'
>
> (I doubt that example would work with imapds as is, but surely a
> conditional expression could do the trick.)
>
> I know it's too late for Postfix 2.9, but is this possible? Does it
> make sense, or would it need too drastic a rewrite?
> --
> http://rob0.nodns4.us/ -- system administration and consulting
> Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
>
