On Fri, 12 Jan 2007, Aleksandar Milivojevic wrote:
Quoting "Paul R. Ganci" ganci@nurdog.com:
I have a user who has Mac OS 10.4.8 with Entourage X. The email server is sendmail 8.13.8 and is setup to use STARTTLS on a CentOS 4.4 system.
[snip]
I have just done the usual stuff that seems to work for Thunderbird, Evolution, Outlook, Mac Mail and the latest Eudora. On the sendmail server side:
define(`confAUTH_OPTIONS', `A p y')dnl TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
(purposely not showing the certificate config)
On the Entourage X client side:
Checked the box "SMTP service requires secure connection (SSL) Checked the box "SMTP server requires authentication Checked the box "Use the same settings as receiving mail server"
Entourage X returns an error indicating:
"The SMTP server for "MRIC" does not recognize any of the authentication methods supported by Entourage."
Maybe the version of Entourage you have doesn't support STARTTLS. Try enabling implicit SSL port in Sendmail's configuration by adding this line:
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')
After adding that line, Sendmail will listen on port 465 (smtps) in addition to port 25. You'll have SSL on port 465, and on port 25 you can have plaintext or TLS (after client issues STARTTLS).
This is good advice, but the question is forcing us to guess. It'd be a lot easier to answer you with some more information:
* what port is Entourage trying to contact? * is it using STARTTLS or straight SMTP/SSL? * could there be any firewalls hijacking traffic?
Assuming you know the IP address of the Mac client machine, try launching a tcpdump session on the mail server
sudo tcpdump -A -s0 host $CLIENT_ADDR
Entourage will try to contact one of three ports:
25 (smtp) 465 (smtps) 587 (submission)
tcpdump will show you what port the client is addressing and whether the client is using STARTTLS (port 25 or 587) or straight SSL (port 465). In the former case, the tcpdump output will include the string 'Ready to start TLS' before any certificate info is sent over the wire. If the connection is straight SSL, it won't be there.
If the client is not on your LAN, it's possible that there's a firewall that's redirecting SMTP traffic, esp. on port 25. To reduce the damage caused by zombies and spambots, lots of networks these days don't allow port-25 packets to go directly to remote mail servers, silently redirecting them to their own servers.