+.PP
+If
+.B nmh
+has been compiled with APOP support, the
+.B \-apop
+switch will cause
+.B msgchk
+to use APOP rather than standard POP3 authentication. Under APOP,
+a unique string (generally of the format
+.RI < pid . timestamp @ hostname >)
+is announced by the POP server.
+Rather than `USER
+.IR user ',
+`PASS
+.IR password ',
+.B msgchk
+sends `APOP
+.I user
+.IR digest ',
+where digest is the MD5 hash of the unique string
+followed by a `secret' shared by client and server, essentially equivalent to
+the user's password (though an APOP-enabled POP3 server could have separate APOP
+and plain POP3 passwords for a single user).
+.B \-noapop
+disables APOP in cases
+where it'd otherwise be used.
+.PP
+If
+.B nmh
+has been compiled with KPOP support, the
+.B \-kpop
+switch will allow
+.B msgchk
+to use Kerberized POP rather than standard POP3 on a given
+invocation. If
+.B POPSERVICE
+was also #defined to "kpop",
+.B msgchk
+will be
+hardwired to always use KPOP.
+.PP
+If
+.B nmh
+has been compiled with SASL support, the
+.B \-sasl
+switch will enable
+the use of SASL authentication. Depending on the SASL mechanism used, this
+may require an additional password prompt from the user (but the
+.RI \*(lq \&.netrc \*(rq
+file can be used to store this password). The
+.B \-saslmech
+switch can be used to select a particular SASL mechanism.
+.PP
+If SASL authentication is successful,
+.B inc
+will attempt to negotiate
+a security layer for session encryption. Encrypted traffic is labelled
+with `(encrypted)' and `(decrypted)' when viewing the POP transaction
+with the
+.B \-snoop
+switch.