Right, I was thinking of hexifying non-printable characters, e.g.,
displaying [0x01]. And assuming ASCII, which if I read RFC 4954
right, is valid ("non-US-ASCII is only allowed as hexchar", where
hexchar is "+" HEXDIG HEXDIG). Maybe that suggests using +01 instead
of [0x01], though I like marking the SASL bytes differently from user
data.
I don't think you can make an assumption what the _decoded_ base64 SASL
tokens are; that is just talking about what appears in the AUTH messages,
not what the tokens contents are. I mean, we can't even make an assumption
with regards to character set without knowing more about the particular
SASL mechanism.
I'd rather not extend the length of the current indications such as
tls-decrypted and sasl-decrypted. tls-b64decryp and sasl-b64decryp ?
Well, if you're using pure SASL encryption/decryption, encryption doesn't
start until SASL is complete, so I'm not sure that works.
Here's an idea. How about:
334 b64<Username:>
b64<username@somewhere>
That would let you know which part of the message is the actual base64 token
(it's different between protocols). Just a thought; I don't have super
strong feelings about this.
And that reminds me all of the TLS/SASL code should be factored into one
set of routines. Sigh. Someday.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers