On 2015-09-03 at 15:25 -0700, AC wrote:
> I'm trying to figure out what's going on with sending mail from my phone
> through my server. It had been working for a while but suddenly
> stopped. I am authenticating using saslauthd for outgoing mail.
My first suspicion is password corruption because of a character which
some system thinks it should escape before it leaves the phone, or a
character not showing, or a homoglyph. You're absolutely sure that the
base64-encoded password which made it to your debug exim instances was
identical in the working and non-working states? Note that if the phone
is sending leading or trailing whitespace, then it might not show up
visibly in debug traces where you're looking at the password, but should
be more obvious in the base64-encoded variant (which should still be
identical across authentication attempts, for plaintext auth). Also ë
vs ë (one character, vs two characters (one combining) composed into a
grapheme) and other things which look similar, but aren't at the byte
level.
Assuming that it's identical and that you're seeing variance in
saslauthd output: it's because of problems debugging the moving parts in
using saslauthd and issues we were getting, that I added the dbmjz
lookup type to exim, which is a DBM-Join-Zero lookup; given the list of
fields, join them on ASCII NUL and use as a lookup key in the DBM file.
This does require that the Exim run-time user have read access to the
sasldb though. It's a trade-off. An example in using this is at:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_crammd5_authenticator.html
(but beware that cram-md5 is using $auth1, not $auth2).
It's better, security-wise, to not give the Exim run-time user direct
access to the sasldb and only grant access via a yes/no daemon running
as a different user. On the other hand, for small setups it might be
acceptable to take the simplicity, and having the _option_ to try this
can help you rule out possible sources of the problem.
-Phil
