On Tue, 15 Dec 2009 15:31:53 +0000 Mike Cardwell wrote:
> 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.
>
Yup, it's a valid concern. Also just pointing out that it doesn't seem to
be really likely/dangerous one. When email came around the X.400 stuff
mentioned in the RFC was quite well established and I assume thus even the
oldest implementations paid attention to that.
Basically any scheme that preserves the original local part (for a
human to figure stuff out again if something goes wrong) AND tags
something onto it is bound to run into this problem.
Another popular inflated local part is generated by various mailing list
systems and bulk mailers, for example VERP:
(goats-list-atsomeplace=usernameyouhavenocontrolover=domainthatmight.belongaswell@???)
And they seem to be doing fine, too. ^_-
> > 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...
>
In one word, KISS. Or to quote from the Middleman: "Sheer elegance in its
simplicity." ^o^
The time data requires a more complex local handling (algorithmic or
keeping a DB of what you issued) and the variable nature of it messes with
various things like list managers, greylisting, etc.
Regards,
Christian
--
Christian Balzer Network/Systems Engineer
chibi@??? Global OnLine Japan/Fusion Communications
http://www.gol.com/
