On 15/12/2009 13:39, Christian Balzer wrote:
>> The example they provide looks dangerous to me:
>>
>> return_path = $sender_address_local_part=$local_part=$domain=\
>> ${hash_8:${hmac{md5}{SECRET}{${lc:\
>> $sender_address_local_part=$local_part=$domain}}}}\
>> @$sender_address_domain
>>
>> Local parts in email addresses have a maximum length of 64 characters,
>> yet that could easily expand to something considerably larger than 64
>> characters...
>>
> From the RFC:
> To the
> maximum extent possible, implementation techniques that impose no
> limits on the length of these objects should be used.
Yeah, it says that. But if you look at the previous few sentences it
makes clear that you "SHOULD" avoid doing what you're doing, and "MUST"
prepare for failures if you do it. I was just bringing attention to
these possible failures in my previous email, that's all.
> Lets just say that I have never seen a rejection/error with this when it
> clearly exceeded 64 characters. Which it does much less often than you'd
> think.
> Basically I picked it because it was simple and did NOT include any time
> based data as in BATV. Similar line of reasoning why our greylisting does
> not include IP addresses.
JOOI, why would you want to avoid the time data? It seems quite useful
to me...
--
Mike Cardwell - IT Consultant and LAMP developer
Cardwell IT Ltd. (UK Reg'd Company #06920226)
http://cardwellit.com/
Technical Blog:
https://secure.grepular.com/blog/
