Fabio Ferrero wrote:
> Tony Finch ha scritto:
>
>>>In a router I've tried this:
>>> local_part_suffix= +${substr{6}{2}{$tod_logfile}}
>>> local_part_suffix_optional
>>>to accept email addressed to user+currentdayofmonth@domain but doesn't
>>>work. The suffix never matches. What's wrong?
>>
>>local_part_suffix is not expanded.
>
>
> Ach...
>
> I've resolved with this router:
>
> ## Accept user-ddmmyyyy@domain and redirect to user@domain
> auto_daily_alias:
> driver = redirect
> check_ancestor
> condition = ${if eq {${substr{-9}{10}{$local_part}}}
> {-${substr{6}{2}{$tod_logfile}}${substr{4}{2}{$tod_logfile}}${substr{0}{4}{$tod_logfile}}}
> {true}{false}}
> data = ${substr{-9}{$local_part}}@$domain
>
>
Three questions:
Observation: looks as if the 'real' $local_part is used as a prefix rather than
a suffix, at least from the viewpoint of this router. Or, put another way, that
the ddmmyyyy is a suffix to $local_part. Whichever... But, if so..
1) If the order were to be reversed, optionally 'dot' separated, might other
Exim parsing tools work as/more easily? i.e. ddmmyyyy.username@???
Tony?
2) If so, might that then permit working around the fixed username length
limitation in the present code?
3) If this is a spam-reduction technique (?) might some known-to-you hash work
better than a simple date? i.e <the day's hash>.username@???
Just curious...
Bill
