this is not neccessarily a strictly exim-related question.
i've been reading various rfcs on smtp and related subjects but can't
get this thing straight:
when there's (forex.) smtp auth going on, certain parts of the
dialogue are conducted in base64-encoded form. rfc2045 (page 25) says:
"
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. [...]
"
rfc2554 says:
"
The BASE64 string may in general be arbitrarily long. Clients
and servers MUST be able to support challenges and responses
that are as long as are generated by the authentication
mechanisms they support, independent of any line length
limitations the client or server may have in other parts of its
protocol implementation.
"
and it doesn't talk about any 76-character wraps, but, it indeed talks
about base64, which in turn seems to require the 76-character wraps
(at most 76 chars that is; my interpretation is that it can be
smaller).
i'm not sure how to interpret this; is there something i missed which,
at least in the smtp dialogue case, says something like "base64
without the 76-character limit" (i actually seem to remember something
like that, but it fades away in distant memory... i think it was wrt
http authentication headers...); or... or i don't know. i tried to
feed exim with wrapped ("\r\n") base64 data, and it spits the first
part back as "invalid base64 data", and invalid command for the rest
(of course). the code in src/auths/b64decode.c indicates this is very
much the intended action.
i know i'm kindof stretching the issue to the extremes, as in the case
of CRAM-anything, longer shared secrets longer than L bytes (as in
rfc2104) for any given H algorithm are hashed with H and the resulting
L long hash is used as the shared secret, but if H is, say, rmd160
(L=20, 40 in hex representation), with even just a moderately long
username + the hexhash of the shared secret, all these b64-encoded,
could easily result in a response longer than 76 chars, at which any
well-behaved base64 encoder should soft-break.
unless, of course, (and i'm quite sure about this) i'm missing
something very obvious.
could anyone please sched some light in the right direction ?
