I've done some more looking into this and discovered that once-upon-a-time Thunderbird had to be modified to deal with this issue too.

Because TBird uses password encryption by default, the solution was to create a user-settable "use secure authentication if possible" option (the default being 'yes'). So, people who ran into this bug could set "use secure authentication if possible = false", which would allow TBird to fall back to PLAIN if CRAM-MD5 failed.

Hello -

I cannot get Pegasus to do any sort of authenticated SMTP on any port.  From my internal network I can send via a plain port 25 connection with Pegasus, but as soon as I try to authenticate, no matter which port or option I use, it fails.  As far as I can tell, Pegasus tries to do CRAM-MD5 and the server doesn't like it.  These are the highlights of a session:

>> 0025 250-ENHANCEDSTATUSCODES
>> 0016 250-PIPELINING
>> 0014 250-8BITMIME
>> 0019 250-SIZE 10485760
>> 0009 250-DSN
>> 0010 250-ETRN
>> 0042 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
>> 0015 250-DELIVERBY
>> 0010 250 HELP
<< 0015 AUTH CRAM-MD5
>> 0054 334 "xyz123"
<< 0058 "xyz123"
>> 0033 535 5.7.0 authentication failed 

Obviously (perhaps) the "xyz123" is my substitution for the BASE64 strings.  When I decode them, the user name is clear, the password is encrypted in some way - every time.

I take this to mean that the server is saying it can access CRAM-MD5 but then it doesn't like what it sees from Pegasus.  I am by no means an expert in the finer details of the various methods of smtp authentication and encryption, but I can say that I have no problem with this in Thunderbird and Outlook.  Outlook is happy with the SMTP over SSL on both port 465 and 587.  Pegasus doesn't like any combination of options with any of the ports (25, 465, 587) - I have literally tried them all.

I have read a lot of web pages concerning this and what I am starting to thing is that while Pegasus may strictly adhere to standards, it may be the case that some hosts don't and maybe most clients don't.  Of course the result is that Pegasus doesn't work with at least some servers while other clients have no problem (my server is running sendmail 8.13).  I have seen more than a few host/isp pages which say that their users can't use Pegasus as a client because of this.  I have been telling people how great and flexible Pegasus is for years and years, so I really hope I don't have to go back to them and tell them to switch because it won't work with this host.  As it is, I am starting to think that is all I can do. 

Your replacement of two different BASE64 strings with the same value may be misleading. De-BASE64ing and translating it along the way, does your log actually look like this: (?)

1. 0042 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
   :::: the server says it can recognizes the challenge-response authentication mechanism (CRAM)
    
2. 0015 AUTH CRAM-MD5
   :::: client says it is going to authenticate using CRAM
    
3. 0054 334 ccccccccgobbledygookcccccccccccccccc
   :::: server sends "ccccccccgobbledygookcccccccccccccccc" as the challenge. The client will need this to generate the digest.
    
4. 0058 username aabbccddeeff00112233445566778899
   :::: client sends "username aabbccddeeff00112233445566778899" as the response.
   .... The "username" is plain text followed by a single space followed by a 16 byte HMAC-MD5 digest in hexadecimal notation (in lowercase).
   .... The digest is computed using the challenge + username + password.
   

Your replacement of two different BASE64 strings with the same value may be misleading. De-BASE64ing and translating it along the way, does your log actually look like this: (?)

1. 0042 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
   :::: the server says it can recognizes the challenge-response authentication mechanism (CRAM)
    
2. 0015 AUTH CRAM-MD5
   :::: client says it is going to authenticate using CRAM
    
3. 0054 334 ccccccccgobbledygookcccccccccccccccc
   :::: server sends "ccccccccgobbledygookcccccccccccccccc" as the challenge. The client will need this to generate the digest.
    
4. 0058 username aabbccddeeff00112233445566778899
   :::: client sends "username aabbccddeeff00112233445566778899" as the response.
   .... The "username" is plain text followed by a single space followed by a 16 byte HMAC-MD5 digest in hexadecimal notation (in lowercase).
   .... The digest is computed using the challenge + username + password.
   

 
The crucial question here is:...   Is - after converting from BASE64 - the string being sent to the server in the format described by #4 above?

When I first tried it after reading your post, I thought the problem was that it isn't lowercase, but then I realized that is *after* it is decoded.

The answer to your question is yes - username single-space 16 bytes all lowercase (after decoding).  It would appear that everything that is supposed to happen, is happening as far as the transactions go, but there must be some sort of mismatch between how the server is expecting the response to the challenge to be encoded and what Pegasus is actually doing.  I would not be surprised if Pegasus is doing exactly what the standard says it should be doing, but apparently that is not exactly what at least some servers and perhaps the 2 most popular mail clients do.  FWIW, when I was googling about this, I got the idea that Eudora behaved the same way as Pegasus up until some particular version.

Following up...

* Are you using Auth only for SMTP or for POP as well?
* Does this happen consitently, or just occasionally?
* Have you tried changing the password for the account for which authenticated smtp doesn't work?
The reason I ask is because not very long ago there was a busted HMAC-md5 implementation floating around which screwed up under some circumstances.

Although I wouldn't be surprised if Pegasus is doing things correctly either, have you checked?

In perl that would amount to something like this:
  use Digest::HMAC_MD5 qw(hmac_md5 hmac_md5_hex);

  print hmac_md5_hex($challenge, $password);
or

  use Digest::HMAC_MD5;
  $hmac = Digest::HMAC_MD5->new($password);

  $hmac->add($challenge);

  print $hmac->hexdigest;

* Are you using Auth only for SMTP or for POP as well?

 I tried that today and it works fine (via port 995).

* Does this happen consistently, or just occasionally?

Every time.

* Have you tried changing the password for the account for which authenticated smtp doesn't work?

 I created new accounts to try this out - no dice.  Plus, this is a newly installed and fully updated/patched server.
 

Although I wouldn't be surprised if Pegasus is doing things correctly either, have you checked?

Today I downloaded something called HashCalc (a free windows utility) to try this and nothing I came up with matches what Pegasus is sending.  I think I tried all reasonable combinations, but could you clarify this:

.... The "username" is plain text followed by a single space followed by a 16 byte HMAC-MD5 digest in hexadecimal notation (in lowercase).
.... The digest is computed using the challenge + username + password.

Exactly what string should I be using to calculate the digest (before base4 encoding it)?  Is it literally challenge<space><plus sign> etc, just a space between, or nothing between?  I also tried just username and password and password only and none of them came out right either.  I used the complete text string that came out of the base64 decode of the challenge as the the HMAC.

If the username were "daisy", the password were "bicycle" and the server's challenge were "<12345.67890@example.com>"
the line in your log that begins with 0058 should look like this:

0058 ZGFpc3kgZTI2ZDlmNzA0MGE5Yzg4NmRmMGM5YzRmNDMzZjIzYzk=
which (base64) decodes to
0058 daisy e26d9f7040a9c886df0c9c4f433f23c9

The hexadecimal number (16 bytes) is the output of the HMAC-MD5

routine and is generated from the password and challenge, where

key=password and data=challenge
There is a single space between "daisy" and the hexadecimal number. This string ("daisy e26d9f7040a9c886df0c9c4f433f23c9") is then base64 encoded and sent to the server.

You can run your values through http://www.webmaster-eye.de/hmac-md5-hash-generieren.html
There, put the password in the "Seed" field, and the challenge in the "String" field. In the result, keep only the first 32 characters (i.e. remove the password that reappears at the end of that result).

You can check that this hash routine is working by feeding it with test case #2 from  http://www.faqs.org/rfcs/rfc2202.html
When you feed the hasher mentioned above with "Seed"="Jefe" and "String"="what do ya want for nothing?" you get "750c783e6ab0b503eaa86e310a5db738Jefe" which matches test #2 but tags on "Jefe" at the end.

Before you do anything more make sure that the server is actully setup to do CRAM-MD5.  Many ESMTP hosts are advertizing that they support this protocol but the system admin has not actually setup the system to make is work.  The ISP will probably tell you to not USE CRAM-MD5 when the real answer should be that they should turn off something they do not support.  A mail client should alway use the most secure method that the host supports.

Well, upon properly testing it, it appears (not surprisingly) that Pegasus is sending the correct challenge response and thus it may be that the server isn't really doing CRAM-MD5.  I can only imagine that Outlook and Thunderbird are reverting to PLAIN or LOGIN when CRAM-MD5 fails - or perhaps that they aren't trying to use it at all.  Given that this is an SSL connection, I have to wonder if there is any point in doing CRAM-MD5.

I suspect my solution now has to be either to get the server to support CRAM-MD5 or to stop advertising it.  Of course if I could somehow force pmail to use the LOGIN method that would work as well.  There wouldn't, by any chance, be any command line options or ini file settings that would do that would there?
 
Thanks to both of you for your responses, but especially to Cyrus for the patient CRAM-MD5 lessons.

[quote user="rustwood"]

Well, upon properly testing it, it appears (not surprisingly) that Pegasus is sending the correct challenge response and thus it may be that the server isn't really doing CRAM-MD5.  I can only imagine that Outlook and Thunderbird are reverting to PLAIN or LOGIN when CRAM-MD5 fails - or perhaps that they aren't trying to use it at all.  Given that this is an SSL connection, I have to wonder if there is any point in doing CRAM-MD5.

I suspect my solution now has to be either to get the server to support CRAM-MD5 or to stop advertising it.  Of course if I could somehow force pmail to use the LOGIN method that would work as well.  There wouldn't, by any chance, be any command line options or ini file settings that would do that would there?
 
Thanks to both of you for your responses, but especially to Cyrus for the patient CRAM-MD5 lessons.

[/quote]

MercuryC is capable of being set to ignore the CRAM-MD5 and I suspect the next version of WinPMail will also get the capability since the code is pretty much the same.