On Wed, 11 Feb 2004, wayne wrote:
First, I actually went and checked and according to RFC2821, the local
part *MAY* be case sensitive, so technically, MTAs can't change the
case, but I think we can't assume this. So, I think base64 encoding
is out, and base36 is probably pretty reasonable.
If we use base64, but allow case insensitive matching on the hash, then we
are effectively base36 with an option to enforce full case insensitivity
if there isn't a problem. Furthermore, we get to use standard base64 code
(which is in everything). We'd have to write our own base36 code, and the
less code in a product, the better, especially in a security-oriented
product.
Secondly, I think a few characters can be squeezed out of the format.
By combining the hash and the timestamp, both binary data, into
one field that is base64 encoded would save at least one character
(the "+" that currently separates them) and possibly a second
character by reducing the number of bits used by the timestamp.
This will be done in v.016. Thank you for the suggestion. We have been
looking at the possibility of shortening the hash. This is now looking
very feasible.
Meng said that he would try to gather up some statistics on how
frequency of different lengths of envelope-froms. Depending on what
this data shows, saving a few characters may be very important, or
completely irrelevant.
So far, only one device is known which has trouble with >64 byte local
parts, and that's the Cisco PIX MailGuard feature. Since PIXs are
notoriously broken anyway, I'm not inclined to panic.
Ok, one other thing that is nagging me about this proposal is that I'm
not certain that this encoding is unambiguous. It makes me nervous
that strings supplied by a third party are left unquoted in the
local-part. In particular, the local-part can contain really nasty
looking stuff, including things that look like domains.
However, I've been checking this, and I can't find any problems. The
old local-part is at the very end rewritten local-part (by design, I'm
almost certain) and the valid characters in a domain name are pretty
limited. RFC2821/2822 say that "+" is not valid in a domain, so it
can be used as a safe delimiter.
This is quite deliberate. I'm afraid my justification for this in the
paper might quite clear. It's a hard thing to explain, somehow. The only
known bug in the Perl implementation is that it does not correctly handle
full RFC282x quoted addresses, which may contain @ signs in the
local-part.
All-in-all, I think the SRS system looks very good. Shevek has
cleared up the cpu usage issue. The only thing I still have questions
about is how big of a problem the 64 character local-part limit is
going to be.
I would still very much like to do a survey of MTAs and gateways to find
out which are compatible and which are not.
Thank you very much for your comments, this is quite encouraging.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/