Re: [exim] authentication against SASL

On 2008-03-14 at 13:44 +0100, Johannes Nohl wrote:
> I don't know where to look now. Is the server_condition right? exim
> doc in packages recommends
>
> server_condition = ${if saslauthd{{$auth1}{$auth2}}}
>
> What is right? $auth1 or $1??

Both, but use $auth1 for anything new being set up. It's clearer and
more likely to stay around and less likely to lead to bugs; spec.txt
explains:

----------------------------8< cut here >8------------------------------
34.2 Using plaintext in a server
--------------------------------

When running as a server, plaintext performs the authentication test by
expanding a string. The data sent by the client with the AUTH command, or in
response to subsequent prompts, is base64 encoded, and so may contain any byte
values when decoded. If any data is supplied with the command, it is treated as
a list of strings, separated by NULs (binary zeros), the first three of which
are placed in the expansion variables $auth1, $auth2, and $auth3 (neither LOGIN
nor PLAIN uses more than three strings).

For compatibility with previous releases of Exim, the values are also placed in
the expansion variables $1, $2, and $3. However, the use of these variables for
this purpose is now deprecated, as it can lead to confusion in string
expansions that also use them for other things.
----------------------------8< cut here >8------------------------------

I can't help much with the saslauthd side of things as I don't use
regular mail passwords for sending mail too. I'll explain why, because
I personally think you should consider the alternative approach, but
I'll then shut up about it.

Dictionary attacks are your enemy here. I use GSSAPI with the
cyrus_sasl driver and, as a fallback, generated long random strings for
the SMTP password, held in a normal lookup file and told people they
could tell their mail clients to remember this long access token, or
write it down, or whatever. It was an access token only used for
sending email and didn't grant access to reading email. This worked and
was accepted even by the least technical staff (who had remote SMTP
access). Worst case scenario with compromise, someone can send mail as
that user. After physically stealing the laptop.

If you're in an environment where you need to protect against reputation
damage from someone who would physically steal machines as a means to an
end, then this approach isn't for you. But then, neither is using
user-generated passwords which are susceptible to dictionary attacks.

-Phil