Outlook 2002 Email Messages Not Opening

I found that when I double-clicked on email messages in Outlook 2002 on a user's system, they would not open. I couldn't open a message by right-clicking on the message and choosing Open either. I was able to eliminate the problem by turning off the Google Desktop add-in within Outlook, which can be done by the following steps:

1. Click on Tools.
2. Select Options.
3. Click on the Other tab.
4. Click on the Advanced Options button.
5. Click on the Add-in Manager button.
6. Uncheck "Google Desktop Search Outlook Addin".
7. Click on OK.
8. Click on Com Add-ins.
9. Uncheck "Google Desktop Outlook Toolbar.
10. Click on OK.
11. Click on OK again.
12. Click on OK to close the Options window.

[/network/email/clients/outlook] permanent link

Sendmail Authorization for Outgoing Email

A CentOS 5.1 email server wasn't allowing email clients, such as Outlook, to relay email through it by providing a userid and password for authorization for outgoing email. I configured an email client, SimpleCheck, to use the same userid and password when sending email as for checking incoming email. I configured it to use the "plain" authorization method when sending email. That didn't work, nor did using "login" or "CRAM-MD5" for the authorization method. I would get an error message stating "'PLAIN' authorization is not supported by the server" when I used the "plain" authorization method. I got similar messages for the other authorization methods.

The server was running sendmail, which supports SMTP AUTH as defined in RFC 2554 which is based on SASL.

The Cyrus SASL package should be installed to enable sendmail to support the AUTH command for authorization. I checked on whether it was installed with rpm -qi cyrus-sasl. I saw it was installed. I then tried sendmail -d0.1 -bv root | grep SASL and saw NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS. The "SASLv2" in the output confirmed that support for SASL was present.

But when I connected to the SMTP port by telnet, I didn't see the AUTH command listed when I issued an ehlo command. And I received messages that the "plain", "login", "cram-md5", and "digest-md5" authorization methods weren't supported when I issued auth commands for those authentication methods.

# telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 example.com ESMTP Sendmail 8.13.8/8.13.8; Tue, 6 May 2008 10:34:34 -0400
ehlo laptop
250-example.com Hello localhost.localdomain [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
AUTH LOGIN
504 5.3.3 AUTH mechanism LOGIN not available
AUTH PLAIN
504 5.3.3 AUTH mechanism PLAIN not available
AUTH CRAM-MD5
504 5.3.3 AUTH mechanism CRAM-MD5 not available
AUTH DIGEST-MD5
504 5.3.3 AUTH mechanism DIGEST-MD5 not available
quit

When I used the testsaslauthd command to check that the saslauthd daemon was installed and running properly, I saw that it was working properly.

# testsaslauthd -s smtp -u jdoe -p HerPassword
0: OK "Success."

You can test SASL support with the testsaslauthd command by specifying a username and its associated password on the system with -u username -p password. The -s service option specifies a particular service. Common service names are "imap", "sieve", and "smtp".

I then looked at /etc/mail/sendmail.mc. I saw define(`confAUTH_OPTIONS', `A')dnl, which provides a list of options for SMTP AUTH was not commented out, so I left it as is. I left the "dnl" at the beginning of the following line, which appeared later in the file. The p option in it would result in sendmail not accepting the PLAIN and LOGIN AUTH methos unless they were protected by a security latyer, such as is provided by STARTTLS.

dnl define(`confAUTH_OPTIONS', `A p')dnl

The sendmail AUTH_OPTIONS options are as follows:

      AuthOptions
                [no short name] List  of  options  for  SMTP
                AUTH  consisting  of  single characters with
                intervening white space or commas.

                    A   Use the AUTH= parameter for the MAIL FROM
                        command only when authentication succeeded.
                        This can be used as a workaround for broken
                        MTAs that do not implement RFC 2554 correctly.
                    a   protection from active (non-dictionary) attacks
                        during authentication exchange.
                    c   require mechanisms which pass client credentials,
                        and allow mechanisms which can pass credentials
                        to do so.
                    d   don't permit mechanisms susceptible to passive
                        dictionary attack.
                    f   require forward secrecy between sessions
                        (breaking one won't help break next).
                    p   don't permit mechanisms susceptible to simple
                        passive attack (e.g., PLAIN, LOGIN), unless a
                        security layer is active.
                    y   don't permit mechanisms that allow anonymous login.

                The first option applies to  sendmail  as  a
                client, the others to a server.  Example:

                    O AuthOptions=p,y

                would  disallow  ANONYMOUS as AUTH mechanism
                and would allow PLAIN and LOGIN  only  if  a
                security  layer (e.g., provided by STARTTLS)
                is already active.  The  options  'a',  'c',
                'd',  'f',  'p', and 'y' refer to properties
                of the selected SASL  mechanisms.   Explana-
                tions  of  these  properties can be found in
                the Cyrus SASL documentation.

I removed "dnl" from beginning of the following 2 lines to uncomment them:

dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

The relevant lines were then as follows:

define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

I then rebuilt the sendmail.cf file from the sendmail.mc file using m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf. I then restarted sendmail with /etc/init.d/sendmail restart.

When I then used telnet to connect to the SMTP port, port 25, on the server, I saw AUTH listed when I issued the ehlo command.

# telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 example.com ESMTP Sendmail 8.13.8/8.13.8; Tue, 6 May 2008 13:44:58 -0400
ehlo laptop
250-example.com Hello localhost.localdomain [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP

Testing with SimpleCheck, I was then able to send a message with it configured to use the PLAIN or the LOGIN authorization mechanism.

References:

1. SMTP AUTH in sendmail 8.10-8.13
   sendmail.org
2. Cyrus SASL for System Administrators
   SEPP Application Catalog
3. sendmail AUTH_OPTIONS
   lists.freebsd.org Mailing Lists
4. Using SMTP AUTH and STARTTLS with sendmail
   A quick start guide for Red Hat/Fedora Linux
   joreybump.com

[/network/email/sendmail] permanent link