Provided by: nmh_1.7.1-6_amd64 bug

NAME

       msgchk - nmh's check for incoming email

SYNOPSIS

       msgchk [-help] [-version] [-date | -nodate] [-notify all/mail/nomail ] [-nonotify
            all/mail/nomail ] [-host hostname] [-user username] [-sasl | -nosasl] [-saslmech
            mechanism] [-initialtls] [-notls] [-certverify | -nocertverify] [-authservice
            service] [-snoop] [users ... ]

DESCRIPTION

       The msgchk program checks all known mail drops for mail waiting for you.  For those  drops
       which  have  mail for you, msgchk will indicate if it believes that you have seen the mail
       in question before.

       The -notify type switch  indicates  under  what  circumstances  msgchk  should  produce  a
       message.   The  default  is  -notify  all  which says that msgchk should always report the
       status of the users mail drop.  Other values for `type' include  `mail'  which  says  that
       msgchk  should  report  the  status  of waiting mail; and, `nomail' which says that msgchk
       should report the status of empty mail drops.  The -nonotify type switch has the  inverted
       sense,  so -nonotify all directs msgchk to never report the status of mail drops.  This is
       useful if the user wishes to check msgchk's exit status.  A non-zero exit status indicates
       that mail was not waiting for at least one of the indicated users.

       If msgchk produces output, then the -date switch directs msgchk to print out the last date
       mail was read, if this can be determined.

   Using POP
       msgchk will normally check all the local mail drops, but if the option “pophost:”  is  set
       in the mts configuration file “mts.conf”, or if the -host hostname switch is given, msgchk
       will query this POP service host as to the status of mail waiting.

       To specify a username for authentication with the  POP  server,  use  the  -user  username
       switch.  The credentials profile entry in the mh-profile(5) man page describes the ways to
       supply a username and password.

       For debugging purposes, there is also a switch -snoop, which will allow you to  watch  the
       POP  transaction take place between you and the POP server.  If -sasl -saslmech xoauth2 is
       used, the HTTP transaction is also shown.

       If nmh has been compiled with SASL support, the -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 netrc file can be used to store this  password,  as
       described  in  the  mh-profile(5) man page).  The -saslmech switch can be used to select a
       particular SASL mechanism.

       If SASL authentication is successful, msgchk 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 -snoop switch; see  the  post  man
       page description of -snoop for its other features.

       If  nmh  has  been  compiled  with  OAuth support, the -sasl -saslmech xoauth2 switch will
       enable OAuth authentication.  The -user switch must be used, and the user-name must be  an
       email  address the user has for the service, which must be specified with the -authservice
       service switch.  Before using this, the user must authorize nmh  by  running  mhlogin  and
       grant authorization to that account.  See the mhlogin man page for more details.

       If  nmh  has  been  compiled  with  TLS  support,  the -initialtls switch will require the
       negotiation of TLS when connecting to the remote POP server.  The -initialtls switch  will
       negotiate  TLS  immediately  after the connection has taken place, before any POP commands
       are sent or received.  Data encrypted by  TLS  is  labeled  `(tls-encrypted)'  and  `(tls-
       decrypted)`  with  viewing  the POP transaction with the -snoop switch.  The -notls switch
       will disable all attempts to negotiate TLS.

       When using TLS the default is to verify the remote certificate and SubjectName against the
       local  trusted  certificate  store.   This  can  be  controlled  by  the  -certverify  and
       -nocertverify  switches.   See  your  OpenSSL  documentation  for  more   information   on
       certificate verification.

FILES

       $HOME/.mh_profile          The user profile
       /etc/nmh/mts.conf          nmh mts configuration file
       /var/mail/$USER            Location of mail drop

PROFILE COMPONENTS

       None

SEE ALSO

       inc(1), mh-mail(5) post(8)

DEFAULTS

       `user' defaults to the current user
       `-date'
       `-notify all'

CONTEXT

       None