On Wed, 17 Nov 2004, Tony Finch wrote:
That's a bad idea: consider
attacker+VERYVERYLONGLOCALPARTSUFFIXWHICHLOOKSLIKEBATV/victim(_at_)domain
I believe the syntax was not correct, it still included "+" which I later
eliminated when simplifying syntax and removing extra special symbols
symbols.
I'm correcting it below.
You missed the point: attacker+anything(_at_)domain is a valid email address:
the attacker can choose any local part suffix appended to their usual
local part with a +.
So?
As for your example even if it was correct syntax, the possibility that
somebody would try to use syntax that looks like BATV exist in current
BATV syntax as well, i.e.
batv=victim/VERYVERYLONGLOCALPARTSUFFIXWHICHLOOKSLIKEBATV(_at_)domain
This, however is an invalid email address since it's using BATV framing
with an invalid tag, rather than local-part suffix framing where any tag
is valid.
What is invalid there?
We're certainly not going to register each tag with IETF, the entire idea
of framework is that you allow people to choose their own tags.
My point was that your altered syntax has widened the possibility of
attacks based on human factors.
I don't see how that is true.
The rationale is to allow multiple signatures to co-exist and allow
signatures of possibly multiple data parts, etc.
That's obvious from your original message. What I mean by a rationale
is an explanation for why is this desirable.
Disirable: scalable extendable syntax (?)
Or can you rephrase it so I understand what you're asking?
-
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net