Postal: CRAM-MD5 problems

[yolleksandr]

Hello guys.
First, thanks for great product.

The problem.
We have old legacy software with CRAM-MD5 only SMTP AUTH mechanism in curl.

When i simulate this method from console i have error:

Command:
curl --url smtp://myserver:25 --mail-rcpt '[email protected]' --mail-from '[email protected]' --user 'me:mypassword' --upload-file message.txt --insecure --login-options AUTH=CRAM-MD5

Console error:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (67) Login denied

Log error:
==> smtp_server.log <== [smtp.1:2293] [2017-11-23T14:16:57.048] DEBUG -- : [BRZAMY] Connection opened from ::ffff:XXXXXXXX [smtp.1:2293] [2017-11-23T14:16:57.048] DEBUG -- : [BRZAMY] Client identified as ::ffff:XXXXXXXX [smtp.1:2293] [2017-11-23T14:16:57.048] DEBUG -- : [BRZAMY] <= EHLO message.txt [smtp.1:2293] [2017-11-23T14:16:57.056] DEBUG -- : [BRZAMY] => 250-My capabilities are [smtp.1:2293] [2017-11-23T14:16:57.056] DEBUG -- : [BRZAMY] => 250 AUTH CRAM-MD5 PLAIN LOGIN [smtp.1:2293] [2017-11-23T14:16:57.094] DEBUG -- : [BRZAMY] <= AUTH CRAM-MD5 [smtp.1:2293] [2017-11-23T14:16:57.094] DEBUG -- : [BRZAMY] => 334 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= [smtp.1:2293] [2017-11-23T14:16:57.094] DEBUG -- : [BRZAMY] <= XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [smtp.1:2293] [2017-11-23T14:16:57.105] DEBUG -- : [BRZAMY] => 535 Denied [smtp.1:2293] [2017-11-23T14:16:57.105] DEBUG -- : [BRZAMY] Connection closed

When i change in curl CRAM-MD5 to LOGIN - all is fine.

How can i work with CRAM-MD5 method on Postal Server?

Env:
postal version: 1.0.0-67d0f6514d-stable

[willpower232]

I believe CRAM-MD5 requires a Base64 value made from your username and password rather than an explicit username and password as used in your command. '535 Denied' suggests that the value is missing or invalid.

Have a look at this https://linuxconfig.org/how-to-perform-auth-digest-md5-cram-md5-command-line-smtp-authentication

I haven't been able to find an example of using curl with CRAM-MD5 so are you able to test it using the legacy software?

[yolleksandr]

Base64 as i understand used for telnet session for generate one time pass from login, password and challenge.

But, for example, PLAIN requires too pregenerated string like perl script:
perl -MMIME::Base64 -e 'print encode_base64("\0login@domain\000password");'
and this works fine (mail send fine) with curl plain text --user option and with telnet session with string from perl command.

Legacy Software not working at the moment, but curl too. Well, telnet session not work too with AUTH CRAM-MD5 command...

Any ideas?

[catphish]

This certainly seems like a bug. I'll try to reproduce it.

[yolleksandr]

Hello guys.
Can i help you with this issue?

[catphish]

Of course, if you can demonstrate some input that fails, and write a fix, it'll be super easy to get it merged. Even if you can just demonstrate exactly how to make it fail, that would be useful.

[phelset]

This possibly happens when the username and password are too long? Which creates a long CRAM-MD5 response?

[lokival]

Good Day,

I believe we're having this problem as well, I saw you requested some input a while ago to help get this bug fixed, do you still need any?

I can provide the logs from the Postal SMTP server on our side which shows AUTH CRAM-MD5 failures.

[catphish]

It would be very useful if you could send me a log of this failing. I can then try to reproduce and give you a shout if I need any other details.

[lokival]

Noted,

See below -

--- Begin Log Excerpt ---
[smtp.1:8804] [2018-06-28T10:03:01.807] DEBUG -- : [BHFHAO] Connection opened from ::ffff:10.1.1.110:03:01.819] DEBUG -- : [BHFHAO] Client identified as ::ffff:10.1.1.18T10:03:01.828] DEBUG -- : [BHFHAO] <= EHLO FortiAnalyzer200Dp.1:8804]
[smtp.1:8804] [2018-06-28T10:03:02.049] DEBUG -- : [BHFHAO] => 250-My capabilities are.1:8804] [2018-06-28T10:03:02.049] DEBUG -- : [BHFHAO] => 250-STARTTLS
[smtp.1:8804] [2018-06-28T10:04:02.427] DEBUG -- : [CPU3ED] Client identified as ::ffff:10.1.1.1
[smtp.1:8804] [2018-06-28T10:04:02.444] DEBUG -- : [CPU3ED] <= EHLO FortiAnalyzer200D
[smtp.1:8804] [2018-06-28T10:04:02.500] DEBUG -- : [CPU3ED] => 250-My capabilities are
[smtp.1:8804] [2018-06-28T10:04:02.500] DEBUG -- : [CPU3ED] => 250-STARTTLS
[smtp.1:8804] [2018-06-28T10:04:02.501] DEBUG -- : [CPU3ED] => 250 AUTH CRAM-MD5 PLAIN LOGIN
[smtp.1:8804] [2018-06-28T10:04:02.538] DEBUG -- : [CPU3ED] <= STARTTLS
[smtp.1:8804] [2018-06-28T10:04:02.538] DEBUG -- : [CPU3ED] => 220 Ready to start TLS
[smtp.1:8804] [2018-06-28T10:04:02.559] DEBUG -- : [CPU3ED] <= EHLO FortiAnalyzer200D
[smtp.1:8804] [2018-06-28T10:04:02.500] DEBUG -- : [CPU3ED] => 250-My capabilities are
[smtp.1:8804] [2018-06-28T10:04:02.500] DEBUG -- : [CPU3ED] => 250-STARTTLS
[smtp.1:8804] [2018-06-28T10:04:02.501] DEBUG -- : [CPU3ED] => 250 AUTH CRAM-MD5 PLAIN LOGIN
[smtp.1:8804] [2018-06-28T10:04:02.538] DEBUG -- : [CPU3ED] <= STARTTLS
[smtp.1:8804] [2018-06-28T10:04:02.538] DEBUG -- : [CPU3ED] => 220 Ready to start TLS
[smtp.1:8804] [2018-06-28T10:04:02.559] DEBUG -- : [CPU3ED] <= EHLO FortiAnalyzer200D
[smtp.1:8804] [2018-06-28T10:04:02.628] DEBUG -- : [CPU3ED] => 250-My capabilities are
[smtp.1:8804] [2018-06-28T10:04:02.628] DEBUG -- : [CPU3ED] => 250 AUTH CRAM-MD5 PLAIN LOGIN
[smtp.1:8804] [2018-06-28T10:04:02.672] DEBUG -- : [CPU3ED] <= AUTH CRAM-MD5
[smtp.1:8804] [2018-06-28T10:04:02.673] DEBUG -- : [CPU3ED] => 334 PDYwZTVhYWQyNjdlNjIyOWI4YTEyQG14Lm1jbC5sb2NhbD4=
[smtp.1:8804] [2018-06-28T10:04:02.674] DEBUG -- : [CPU3ED] <= Zm9ydGlnYXRlQG0uYW1wbGlhLmNvLnR0IGNkNjJjOWRkMzliNDk5MzA0ZDU1ZDIzNWY4YzllYjIx
[smtp.1:8804] [2018-06-28T10:04:02.713] DEBUG -- : [CPU3ED] => 535 Denied
[smtp.1:8804] [2018-06-28T10:04:02.715] DEBUG -- : [CPU3ED] Connection closed

--- End Log Excerpt ---

[lokival]

Update,

Tried testing manually with known good credentials via telnet, see output below -

-- Begin Telnet Session --

20 mx.mcl.local ESMTP Postal/UPGSZZ
EHLO testing
250-My capabilities are
250-STARTTLS
250 AUTH CRAM-MD5 PLAIN LOGIN
AUTH CRAM-MD5
334 PGVhZDAwNTA5MzkzYjI4YjRhZTY3QG14Lm1jbC5sb2NhbD4=
dGVzdEBtLmFtcGxpYS5jby50dCA2NDQyOTA0ZGQ5MWE4NGI0NWU3ZTVmNDRlNmRlYjRhNA==
535 Denied
quit
221 Closing Connection

Connection to host lost.

--- End Telnet Session ---

The challenge response was generated with gen-auth version 20060620.0

Hope this helps, let me know if you need any other info.

[catphish]

Tried testing manually with known good credentials via telnet, see output below -

This is extremely useful, thanks. Are you able to share the password that was used for this interaction? Obviously only do so if it's no longer a live account.

[catphish]

I've just tested this using a password of my choosing and the same challence and I can't seem to reproduce the problem :slightly_frowning_face:

encryption type: cram-md5
username: [email protected]
password: llama
challenge: PGVhZDAwNTA5MzkzYjI4YjRhZTY3QG14Lm1jbC5sb2NhbD4=
dGVzdEBtLmFtcGxpYS5jby50dCA5ZTUzMGNlN2RlNjQzZDNmYjUwYjAzZjU0YzNlZjgzYw==

2.3.7 :011 >   challenge = Base64.decode64('PGVhZDAwNTA5MzkzYjI4YjRhZTY3QG14Lm1jbC5sb2NhbD4=')
 => "<[email protected]>" 
2.3.7 :012 > correct_response = OpenSSL::HMAC.hexdigest(CRAM_MD5_DIGEST, 'llama', challenge)
 => "9e530ce7de643d3fb50b03f54c3ef83c" 
2.3.7 :013 > username, password = Base64.decode64('dGVzdEBtLmFtcGxpYS5jby50dCA5ZTUzMGNlN2RlNjQzZDNmYjUwYjAzZjU0YzNlZjgzYw==').split(' ', 2).map{ |a| a.chomp }
 => ["[email protected]", "9e530ce7de643d3fb50b03f54c3ef83c"] 
2.3.7 :020 > password == correct_response
 => true 

[lokival]

lol

Base64 decode will give them up anyway :)

That's odd,

Perhaps the earlier comment about the length of the password is accurate?

See below for the credentials used in testing the above log entries -

[email protected] - HqYrZMs73PSrxI4urfH7YP5a

[email protected] - h8tDMHSKveG9XNmdlHEsVKCm

[catphish]

Base64 decode won't give them up, this is why CRAM-MD5 is more secure than basic auth.

I have now tried this using telnet and it's failing, so I have something to debug :+1:

[lokival]

Base64 decode won't give them up, this is why CRAM-MD5 is more secure than basic auth.
ah, good to know

correction, should be:

[email protected] - h8tDMHSKveG9XNmdlHEsVKCm

[catphish]

Yeah this is definitely broken. I can't authenticate with CRAM-MD5 at all via telnet :slightly_frowning_face:

[lokival]

Silly question: Does this credential work with other types of SMTP auth?

yes, however note that we have "Send as any" enabled on the server settings.

Yeah this is definitely broken. I can't authenticate with CRAM-MD5 at all via telnet

note, on one of our other devices, when the AUTH fails via CRAM-MD5 it automatically re-tries with AUTH-PLAIN and succeeds using the same credentials.

Unfortunately, not all our devices support this feature, so we have to bug you guys

:)

[catphish]

I see the problem! The username is wrong.

It should be in the format org/server. If you browse to the credentials page, and click "Read more about sending outgoing e-mails" it will give you the correct username.

The username is ignored for PLAIN auth because the password is sent in plain text and can be looked up directly. CRAM-MD5 requires more cryptographic magic, so it has to look up the server first!

It seems very likely that this is the same cause of the problem for other people, because it's not made very clear on the authentication page.

[lokival]

That's done the trick,

Thanks a lot!