[Roger Moser]
An alternative encoding would be base41 (just invented by me)
to encode 2
bytes into 3 characters using following characters:
abcdefghijklmnopqrstuvwxyz0123456789_+-*=
Not accepting slashes would seem to put that MTA in violation of RFC
2821, since the part before the @ sign is supposed to allow almost
anything. Any ASCII character other than @ is techinically
permissible. Some guidance is offered, however:
"While the above definition for Local-part is relatively permissive,
for maximum interoperability, a host that expects to receive mail
SHOULD avoid defining mailboxes where the Local-part requires (or
uses) the Quoted-string form or where the Local-part is case-
sensitive. For any purposes that require generating or comparing
Local-parts (e.g., to specific mailbox names), all quoted forms MUST
be treated as equivalent and the sending system SHOULD transmit the
form that uses the minimum quoting possible.
Systems MUST NOT define mailboxes in such a way as to require the use
in SMTP of non-ASCII characters (octets with the high order bit set
to one) or ASCII "control characters" (decimal value 0-31 and 127).
These characters MUST NOT be used in MAIL or RCPT commands or other
commands that require mailbox names."
And the act of changing the capitalization of the email address while
processing would also probably be some sort of violation of RFC-2821,
I don't have a reference for that.
However, if people actually decide they do want to accomodate
non-RFC-compliant MTAs in SRS:
RFC-3548 describes BASE32 encoding, which is case insensitive, and
already well-defined and available in many programming libraries. It
encodes each group of 40 input bits as But we still have those
irritating equals signs in the address, which some MTAs still won't
like.
Why not just use hex (BASE16)? I mean, it's verbose, but EVERY mta
accepts 0-9 and a-f as the address part. Who cares if the source
address is 80 bytes long? RFCs specify line lengths up to 1000
characters.
Regards,
Ryan