Email authentication problem on only some of Verizon's servers

Question

I use Eudora 6.2.4 on an iMac Core 2 Duo 2.0 20" (Al) Macintosh running OX 10.5.5.  Like many others (see one thread each under FiOS Internet and High Speed Internet and Dialup), since about mid-November, I have been receiving intermittent (about 10% of the time) authentication errors when Eudora checks for new mail.  I have 3 VZ e-mail accounts and one at my employer; the errors occur only on the VZ accounts.
I've used the freeware app Eavesdrop (http://code.google.com/p/eavesdrop/) to observe the TCP conversations between Eudora and the server. The VZ server offers SASL CRAM-MD5 PLAIN, and Eudora uses CRAM-MD5.  I see the challenge from the server, Eudora's response, and the server's authentication-failure response.  Since the response is hashed, I have no way of telling if Eudora is sending the correct response, but it works most of the time.  (After it fails, Eudora then assumes its stored password is NG, discards it, and prompts me for it on the next mail-check, which is just a bit annoying.)
Here is an example of a successful mail-check:
+OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.2-6.01 (built Apr  3 2006)) <[email protected]>
CAPA
+OK list follows
TOP
PIPELINING
UIDL
RESP-CODES
AUTH-RESP-CODE
USER
SASL PLAIN CRAM-MD5
IMPLEMENTATION MMP-6.2p6.01 Apr  3 2006
auth CRAM-MD5
+ PDQ5MzU1ZWY3LmRlZWZlMEB2bXMxMDkubWFpbHNydmNzLm5ldD4=
amp3b2xmOSA3MDA0MmE5YWQwYzEzOWRkYjE5NDk0OWZjYjY1NzBmMg==
+OK Maildrop ready
STAT
+OK 0 0
QUIT
And here's a failure:
+OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) <[email protected]>
CAPA
+OK list follows
TOP
PIPELINING
UIDL
RESP-CODES
AUTH-RESP-CODE
USER
SASL CRAM-MD5 PLAIN
IMPLEMENTATION MMP-6.3p7.04 Sep 26 2008
auth CRAM-MD5
+ PGZjMDAxY2M0ZjZlNDAyNjM3ZTI1MTVmMGU1MWEyYzVjQHZtczE3MTAxMy5tYWlsc3J2Y3MubmV0Pg==
amp3b2xmOSA1NWNmNzJhYzRhZDdlMmE1ZGExZmIwZDVkMzA3NTc5OQ==
-ERR [AUTH] Authentication failed
You'll notice that the VZ server identifies itself at the onset of each conversation, including a build ID and date, followed by a timestamp and a server ID (e.g., vms109.mailsrvcs.net).  I'm in eastern Massachusetts, and when my client connects to incoming.verizon.net, one of a pool of V servers responds.  I've observed about 15 different servers, of which two (vms171011 and vms171013) show "6.3-7.04 (built Sep 26 2008)" and all the others show "6.2-6.01 (built Apr  3 2006)".  Furthermore, I observe that vms171011 and vms171013 consistently give this authentication failure for CRAM-MD5, but all the others (with the older build) consistently succeed in authenticating my accounts.
I called FiOS Support, and the CSR took down took down some relevant info, said she'd pass it on the the e-mail folks.  Within 2 hours I got a call from a Verizon tech.  He said they "knew" about it and that it was a Mac problem.  It wasn't specific to VZ, and it occurred only on Macs.   He had no explanation for my observation that mail-check authentication works with 13 of VZ's servers and consistently fails with two which have a later build version/date, but he believed it was consistent with it being an Apple problem.  So naturally he was off the hook.
He referred me to an Apple Support Forum discussion to back up his position.  I hadn't seen (or thought of looking in) the Apple forums, so I had a look and found a total of 5 threads under "Mail and Address Book".  Of course, these deal with Mail.app, .  Comcast as well as VZ.  This is the lengthiest of them:
  http://discussions.apple.com/message.jspa?messageID=8478765#8478765 
These Apple discussion threads and the two Verizon Forum threads all mention Macintoshes, which lends credence to the tech's assertion that it's a Mac problem, not Verizon's.  I've found one that seems to depict the same thing on a PC (http://groups.google.com/group/comp.mail.eudora.ms-windows/browse_thread/thread/b426c0ca59841ca9), but it's not conclusive. 
I don't know what PeeCee users use for a mail client or what method they use for authentication (the POP3 protocol, as amended,has several possibilities).  My Eudora app has settings for "Password", "Kerberos", and "APOP", but VZ doesn't offer Kerberos, and Eudora seems to ignore the APOP setting, so it uses only the CRAM-MD5 method, so I'm stuck.  I can't disprove that this is a Mac-only problem, but I can't understand why the CRAM-MD5 authentication always works with 13 of VZ's servers and always fails with 2 others (which happen to have a different build version/date).
Solved!
Go to Solution.

Answer 1

With the help of a Windows-using friend, I have additional evidence that the mail-check authentication problem is NOT Mac-specific, but also can be shown to occur with a POP3 client (the final version, Eudora 7.1.0.9) using a secure authentication method (APOP) on Windows (XP Home, SP 3).  He had been observing no authentication problems, but investigation showed that his authentication setting was for "Password", which uses the basic (and very insecure) USER/PASS messages.  His Eudora does not allow CRAM-MD5, but it does have APOP authentication, which is another secure method that also uses the MD5 algorithm to encrypt the password.
When he changed the setting to use APOP authentication, he observed the same behavior that I've reported above:
   - with most of the VZ servers (e.g., vms095.mailsrvcs.net, vms104.mailsrvcs.net) that show "6.2-6.01 (built Apr  3 2006)", the authentication succeeds
   - with vms171011.mailsrvcs.net and vms171013.mailsrvcs.net, which show "6.3-7.04 (built Sep 26 2008)", the authentication fails.
See examples below.
Here's a successful mail-check (these excerpts are from the Eudora log; I've edited his username):
3244    64:13.20 Rcvd: "+OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.2-6.01 (built Apr  3 2006)) <[email protected]> [ISafe POP3 Proxy] \r\n"
3244    32:13.20 Sent: "CAPA\r\n"
3244    64:13.20 Rcvd: "+OK list follows\r\n"
3244    64:13.20 Rcvd: "TOP\r\n"
3244    64:13.20 Rcvd: "PIPELINING\r\n"
3244    64:13.20 Rcvd: "UIDL\r\n"
3244    64:13.20 Rcvd: "RESP-CODES\r\n"
3244    64:13.20 Rcvd: "AUTH-RESP-CODE\r\n"
3244    64:13.20 Rcvd: "USER\r\n"
3244    64:13.20 Rcvd: "SASL PLAIN CRAM-MD5\r\n"
3244    64:13.20 Rcvd: "IMPLEMENTATION MMP-6.2p6.01 Apr  3 2006\r\n"
3244    64:13.20 Rcvd: ".\r\n"
3244    32:13.20 Sent: "APOP XXXXX 8a45b60f3f4a52a472937e86edbfda70\r\n"
3244    64:13.21 Rcvd: "+OK Maildrop ready\r\n"
3244    32:13.21 Sent: "STAT\r\n"
3244    64:13.21 Rcvd: "+OK 0 0\r\n"
3244    32:13.21 Sent: "QUIT\r\n"
3244    64:13.21 Rcvd: "+OK\r\n"
And here's one that fails; note the different server build-date:
460     64:13.23 Rcvd: "+OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) <[email protected]> [ISafe POP3 Proxy] \r\n"
460     32:13.23 Sent: "CAPA\r\n"
460     64:13.23 Rcvd: "+OK list follows\r\n"
460     64:13.23 Rcvd: "TOP\r\n"
460     64:13.23 Rcvd: "PIPELINING\r\n"
460     64:13.23 Rcvd: "UIDL\r\n"
460     64:13.23 Rcvd: "RESP-CODES\r\n"
460     64:13.23 Rcvd: "AUTH-RESP-CODE\r\n"
460     64:13.23 Rcvd: "USER\r\n"
460     64:13.23 Rcvd: "SASL CRAM-MD5 PLAIN\r\n"
460     64:13.23 Rcvd: "IMPLEMENTATION MMP-6.3p7.04 Sep 26 2008\r\n"
460     64:13.23 Rcvd: ".\r\n"
460     32:13.23 Sent: "APOP XXXXX ab2dde7d89cbbf0bf9cd409dce02e5a8\r\n"
460     64:13.27 Rcvd: "-ERR [AUTH] Authentication failed\r\n"
IMHO all this evidence validates my original hypothesis, that two (or more) of VZ's mail servers, which have server builds "6.3-7.04 (built Sep 26 2008)", advertise secure CRAM-MD5 and APOP authentication capabilities, but consistently fail such authentication attempts.  All the other servers with builds "6.2-6.01 (built Apr  3 2006)" handle these authentications correctly.  This has been shown to be the case on both Mac and Windows POP3 email clients.  Email clients that use the simpler and unsecure USER/PASS and AUTH PLAIN methods apparently see no authentication errors on any of the VZ servers.  This strongly points to this being a Verizon problem specific to two of the servers that we see here in eastern Massachusetts.  Others have also observed the same server-specificity; see for example http://eudorabb.qualcomm.com/showthread.php?t=13802 .  This problem has been reported since about mid-November.
Verizon, the ball is in your court.  Find the problem and fix it!