Email authentication problem on only some of Verizon's servers

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)) <49355ef7.deefe0@vms109.mailsrvcs.net>
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)) <745fa06cd9eec4dbd26f249f39ad1b7f@vms171013.mailsrvcs.net>
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).

Accepted answers

JerryW

Yesterday, after posting the above data, I again called FiOS support [Note: this problem is not specific to FiOS or DSL] to report this problem, citing this forum thread as documentation. The CSR filed another Trouble Report and referred it to another part of VZ Technical Support for investigation. This afternoon I received a followup call reporting that the problem I reported "has been isolated and fixed."

This evening I repeated my observations of mail-checks as above, using Mac OS 10.5.5, Eudora 6.2.4 and Mail.app 3.5:

- With Eudora (which uses CRAM-MD5 for secure authentication), in 98 mail-checks across three VZ email accounts, I got the two 2008-build servers 12 times, and the authentication succeeded in all cases; in the 86 cases that used the 2006-build servers, the authentication failed once (using vms109.mainsrvcs.net). Of 85 successful authentications, 5 others were on vms109.mainsrvcs.net, so the failure isn't server-specific.

- With Mail.app (using APOP for secure authentication), in 70 mail-checks across two accounts (9 on 2008-build servers and 61 on 2006-build servers), the authentication succeeded in all cases.

Conclusion: the consistent server-build-specific secure-authentication failures reported over tha past 2+ weeks indeed seem to have gone away, at least for the collection of VZ email servers that I encounter here in eastern Massachusetts (I don't know if users in other areas of the country see the same servers that I do). That single failure on vms109.mailsrvcs.net is troublesome, but it doesn't fit the previously observed pattern. Perhaps it was a cosmic ray...

I have set my email clients back to using secure authentication methods, and I suggest other users do the same instead of using the insecure PLAIN and USER/PASS options. I hope this is the end of it!

All comments

JerryW

Here's some additinal info on this server-specific mail-checking authentication problem.

I also have Apple's Mail.app (version 3.5), which offers "Password" (the basic USER/PASS interaction), "APOP", and "MD5". With USER/PASS, I observe no authentication failures, no matter which server; this alternative is risky, since it sends the user's name and password in the clear:

+OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) <e0f086aa5fd838ed4e8ac0f07cb5edaf@vms171011.mailsrvcs.net>
USER XXXXXXX@verizon.net
+OK password required for user XXXXXXX@verizon.net
PASS foo25bar
+OK Maildrop ready
STAT
+OK 0 0
QUIT
+OK

With MD5 and APOP, I observe consistent authentication-failures on exactly the same servers as I described above with Eudora use. When APOP fails, Mail returns an error to the user, but with MD5, when Mail receives an MD5 failure it immediately tries again with USER/PASS:

+OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) <de78f958a924297492ea56aba4ef211@vms171013.mailsrvcs.net>
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
+ PDkzNDE2N2Q2Y2FjNzQ3OWM4NzFhN2U4MzFlZGFhMjllQHZtczE3MTAxMy5tYWlsc3J2Y3MubmV0Pg==
amp3b2xmOUB2ZXJpem9uLm5ldCBlYzU5MmMxYWQ4ODc2NjhjODc4Yzg0MmE0ZTdlMzIxYg==
-ERR [AUTH] Authentication failed
USER XXXXXXX@verizon.net
+OK password required for user XXXXXXX@verizon.net
PASS foo25bar
+OK Maildrop ready
STAT
+OK 0 0
QUIT
+OK

For Mail.app users, I suggest that the always-insecure "Password" choice is inferior to "MD5", which is secure when it works most of the time, and only occasionally has to fall back to the insecure USER/PASS alternative.

But the question remains, why do Verizon's later-build servers (vms171011 and vms171013) consistently fail with MD5 and APOP, where the other servers appear to operate properly and consistently?

JerryW

I've also downloaded and tried Mozilla Thunderbird 2.0.0.18, and I've found no authentication failures. Thunderbird offers no authentication preferences, and observation shows that it uses AUTH PLAIN, which seems to be handled correctly by all of VZ's servers.

TomB

I have been having the same problem with the same Eudora-iMac configuration and have made similar the same observation as to failures only and always on 2008 version servers. There are some suggestions at http://groups.google.com/group/comp.mail.eudora.mac/browse_thread/thread/c97baf21ad460925?pli=1. Also had the same problem with Apple mail set to APOP which is cured by changing authentication to MD5 challenge-response. The suggestion in the google groups link to change timeout parameters has not helped. The suggestion to disable MD5 in Eudora doesn't seem attractive because all incoming authentication would be PLAIN. However sending authentication in Eudora seems to be PLAIN so it appears that we are not getting all that much password security using MD5 for incoming. The beta version of a Eudora substitute, Odysseus, does not have the sporadic authentication problem although I have no idea what authentication mechanism it uses.

TomB

I tried eavesdrop using odysseus and it uses USER/PASS.

JerryW

TomB -- the USER/PASS explains why you see no authentication failures. I observed earlier that all the VZ mail servers work well with this basic (and very unsecure) authentication mechanism.

I've also learned recently that Eudora 7.1 on Windows defaults to USER/PASS.

cheers,

jerry

JerryW

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)) <4936efbd.1fd9210@vms109.mailsrvcs.net> [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)) <a32cd1e03554a55b4e62b93773cf98eb@vms171013.mailsrvcs.net> [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!

JerryW

This evening I repeated my observations of mail-checks as above, using Mac OS 10.5.5, Eudora 6.2.4 and Mail.app 3.5:

- With Mail.app (using APOP for secure authentication), in 70 mail-checks across two accounts (9 on 2008-build servers and 61 on 2006-build servers), the authentication succeeded in all cases.

I have set my email clients back to using secure authentication methods, and I suggest other users do the same instead of using the insecure PLAIN and USER/PASS options. I hope this is the end of it!

TomB

I also found 5 instances tonight where Eudora successfully authenticated to the 2008 version servers, three times to vms1710001 and twice to vms171013. beginning at 7:10 PM. I did have one failure to a 2006 version server yesterday but two subsequent attempts to the same server succeeded. I am in Maryland.

Wed Dec 03 14:50:46 2008

18635776 262144:9.18.36 DNS Lookup of "incoming.verizon.net"

18635776 262144:0.0.0 206.46.232.10 (1)

18635776 16:0.0.0 Contacting incoming.verizon.net (206.46.232.10)...

18635776 262144:0.0.0 Connecting to 206.46.232.10:110

18635776 262144:0.0.3 Connected to 206.46.232.10:110

19504128 262144:0.0.4 DNS Lookup of "adserver.eudora.com"

19504128 262144:0.0.4 192.190.109.20 (1)

19504128 262144:0.0.4 Connecting to 192.190.109.20:80

18635776 16:0.0.14 +OK Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.2-6.01 (built Apr 3 2006)) <4936e316.159418a8@vms108.mailsrv

18635776 16:0.0.14 CAPA

18635776 262144:0.0.34 SASL mech PLAIN understood

18635776 262144:0.0.34 SASL mech was now PLAIN

18635776 262144:0.0.34 SASL mech CRAM-MD5 understood

18635776 262144:0.0.34 SASL mech was PLAIN now CRAM-MD5

18635776 16:0.0.34

18635776 16:0.0.34 AUTH

18635776 8:0.3.58 AUTH

18635776 8:0.3.58 "-ERR [AUTH] Authentication failed

-6.2pLogging into the POP server.

18635776 8:0.3.58 POP

18635776 8:0.3.58 “I said: AUTH

And then the POP server said: "-ERR [AUTH] Authentication failed

-6.2pLogging into the POP server.” “”

18635776 8:0.3.59 PASS

18635776 8:0.3.59 -ERR [AUTH] Authentication failed

18635776 8:0.3.59 POP

18635776 8:0.3.59 “I said: PASS

And then the POP server said: -ERR [AUTH] Authentication failed” “”

18635776 16:0.4.1

jrodella

I am in the Pittsburgh area and the APOP is still not working. The only solution at this time is to use the password.