An issue was reported in how cyrus-sasl did not reliably terminate its output from the sasl_encode64() function. During an audit of programs that use sasl_encode64(), it was found that sendmail has some questionable uses in sendmail/usersmtp.c, where it just allocates a large output buffer without any appropriate checks against the size of the input buffer. The strings in question are not used for anything odd; they are simply copied elsewhere. This means that we are going to see a crash, leaking some memory to the server, or auth failures. More information on the issue as originally reported against cyrus-sasl (CVE-2009-0688) is available in bug #487251.
For the sake of completeness - in sendmail, sasl_encode64() is also used in sendmail/srvrsmtp.c. Buffer to store base64 encoded representation of the authentication string is allocated dynamically. Size if computed using the ENC64LEN macro, which does not return value that is multiple of 4, and hence sasl_encode64 will always null-terminate or return error.
Uses of sasl_encode64 in sendmail/usersmtp.c are harmless too. Output buffer to store base64-encoded string - in64 - is only used as an argument to smtpmessage(). in64 can only be missing proper null termination when is got fully filled by sasl_encode64(), i.e. MAXOUTLEN (8192) bytes were written to it. smtpmessage() accepts printf-like arguments (format string + arguments) and uses sendmail-specific vsnprintf-like function sm_vsnprintf to prepare the output string in the intermediate buffer SmtpMsgBuffer. Size of the buffer is MAXLINE (2048), hence memory locate after in64 will not be copied it, so memory disclosure is not possible. Only remaining risk is that in64 is printed to the output buffer using '%s' format, which internally calls strlen on the argument. This strlen call can over-read in64 buffer, but can not reach far enough to trigger SEGV, as it stops at the first '\0' byte anywhere on the stack above in64 (e.g. main's argc / argv, or area storing args and environment variables located above the stack). No security implications.