VICIdial POP3 Auth Mode explained (APOP, CRAM-MD5, PASS)

Auth Mode controls how VICIdial proves who it is to a POP3 mail server. Here is what BEST, APOP, CRAM-MD5, and PASS each mean and when to override the default.

When you connect a POP3 mailbox to VICIdial, one field decides how it proves its identity to the mail server: Auth Mode. It only applies to POP3 accounts, and most of the time you can leave it alone. But when a mailbox refuses to log in, this is usually the field you change.

Getting it right matters because a mailbox that won't authenticate quietly starves the whole group. No login means no new email reaches an Agent, no record gets pulled, and nothing for them to Disposition. So it pays to understand the four choices.

The four modes

BEST: the default. It tries APOP first, then CRAM-MD5, then falls back to PASS. It picks whatever the server appears to support and can actually log in with.
APOP: uses an MD5 checksum so your password is not sent in cleartext. It only works if the server genuinely supports it.
CRAM-MD5: also uses an MD5 checksum instead of a cleartext password. Same idea as APOP, a different challenge method.
PASS: sends the password in cleartext. Less private, but it works when the checksum methods fail.

APOP and CRAM-MD5 are the safer options because the password never crosses the wire in plain text. PASS is the blunt fallback. If the server does not claim to support either checksum method, the cleartext route is used anyway.

How BEST walks the ladder

flowchart TD
  A["BEST starts"] --> B{"Server supports APOP"}
  B -->|yes and login works| C["Use APOP"]
  B -->|no| D{"Server supports CRAM-MD5"}
  D -->|yes and login works| E["Use CRAM-MD5"]
  D -->|no| F["Fall back to PASS"]
  C --> G["Mailbox authenticated"]
  E --> G
  F --> G

Some servers put a timestamp in the greeting banner that makes them look like they support APOP, but the login still fails, for example when the server does not hold your password in cleartext. The same trap exists for CRAM-MD5. If your credentials are correct but login keeps failing, force PASS for that server.

So the practical rule is simple. Leave Auth Mode on BEST and let it sort itself out. BEST is built to find the most private method the server will actually accept, then fall back gracefully, so for the large majority of mailboxes you never touch this field at all. If a mailbox stubbornly refuses to connect even though the username and password are right, step down to PASS as a test. If that works, you have found a server whose banner is misleading the checksum negotiation, and pinning the mode to PASS makes the connection stable instead of leaving BEST to fail the same handshake every cycle.

When you do force a mode, choose deliberately. Prefer APOP or CRAM-MD5 if the server genuinely supports them, since both keep your password off the wire as plain text. Only drop to PASS when the checksum methods cannot log in, because PASS sends the password in cleartext and you would rather not do that without a reason. The point of testing PASS is to confirm where the problem is, not to leave every mailbox on the least private option by default.

Keep in mind this field has nothing to do with how email is routed to people once it is in. Which Ingroup gets the message, and which Closer or agent picks it up, is decided separately. Auth Mode is purely the handshake at the mailbox door, and it only exists on POP3 accounts. An IMAP account never shows this setting at all, so if you are weighing the two protocols, that is one less knob to worry about on the IMAP side.

If you are still wiring up the account itself, walk through connecting a POP3 inbox first, then come back to this field. For how email groups sit beside chat and voice, the inbound email and chat guide has the full map. And if mail authentication and module wiring is more fiddling than you want, our pricing page lays out managed plans with the email stack ready to go.