Few comments:

- Cyrus SASL library is required for SASL support. You can download the latest
  version from: ftp://ftp.andrew.cmu.edu/pub/cyrus-mail

- SASL authentication is performed with "spop3d" user privileges.
  Authentication result is sent to privileged process, so if attacker
  gains control over "spop3d" user, he/she is able to authenticate
  as any user. Standard password and APOP authentication schemes seem
  to be safer.

- You should upgrade your Cyrus SASL library to at least 1.5.24 version.
  Earlier versions (1.5.21 for sure) have nasty security bug. There is
  workaround available in Solid POP3, but it's disabled by default.
  You can enable this workaround by changing "0" to "1" in line 408
  in src/spsasl.c file, but upgrading Cyrus SASL is a better idea.

- You can't use non-IP based virtual hosting with SASL authentication.
  AllowNonIP option is ignored when SASL authentication is used.

- You can use user mapping with some SASL mechanisms, but remember that most
  SASL mechanisms authenticate you only if you use the same username/realm
  pair for secret creation and for logging in. Read pop_sasl(1) manual
  for details.

- You can't use user mapping with SASL mechanisms, which don't use user's
  secret for authentication. These include EXTERNAL, KERBEROSV4 and GSSAPI
  mechanisms. DoMapping option is ignored, when these mechanisms are in use.
  PLAIN, DIGEST-MD5, CRAM-MD5 mechanisms work well with user mapping.

- SASL secret may be quite large (4 + 119 = 123 bytes on my machine
  for CRAM-MD5, DIGEST-MD5, PLAIN mechanisms), so if you use SASL
  with domain-per-uid mechanism, make sure your GDBM/DBM/NDBM library
  can handle such size properly. GDBM seems to work well.
