Can you give more links when you say it is recommended in the postfix docs and also say what you have tried?

In The SPTP server there is the option to enable authentication and to block plain text passwords, but personally I do not like enabling SMTP authentication as it opens port 25 to user/pass attack. Have a look at the document I linked to earlier on Antispam and Email Defence measures. I am not sure of the benefits of encrypted passwords on port 587. This is already a TLS connection and shuold be secure before the passwords are transmitted.

It you read the postfix documentation it takes you through cyrus libraries and beyond. Cyrus is already set up to use ldap.

In your logs, what is connecting to 127.0.0.1 as that is an internal connection. Is it kopano or part of the internal mail processing? As far as I can see CRAM-MD% is deprecated and DIGEST-MD5 should be used instead

Do you know how you got it working in 6.x? most configs should copy over from 6.x to 7.x.

(Cyrus is the default)

saslauthd - Cyrus SASL password verification service

Communication between the Postfix SMTP server (read: Cyrus SASL's libsasl) and the saslauthd server takes place over a UNIX-domain socket. 

saslauthd usually establishes the UNIX domain socket in /var/run/saslauthd/ and waits for authentication requests. The Postfix SMTP server must have read+execute permission to this directory or authentication attempts will fail. 

Important 

Some distributions require the user postfix to be member of a special group e.g. sasl, otherwise it will not be able to access the saslauthd socket directory. 

The following example configures the Cyrus SASL library to contact saslauthd as its password verification service: 

/etc/sasl2/smtpd.conf:

    pwcheck_method: saslauthd

    mech_list: PLAIN LOGIN

Important 

Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when using saslauthd! It can only handle these two mechanisms, and authentication will fail if clients are allowed to choose other mechanisms. 

Important 

Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted. This information should be protected by an additional security layer such as a TLS-encrypted SMTP session (see: TLS_README). 

Additionally the saslauthd server itself must be configured. It must be told which authentication backend to turn to for password verification. The backend is selected with a saslauthd command-line option and will be shown in the following examples. 

Note 

Some distributions use a configuration file to provide saslauthd command line options to set e.g. the authentication backend. Typical locations are /etc/sysconfig/saslauthd or /etc/default/saslauthd.

{snip}

Using saslauthd with PAM

Cyrus SASL can use the PAM framework to authenticate credentials. saslauthd uses the PAM framework when started like this: 

% saslauthd -a pam

Note 

PAM configuration for the Postfix SMTP server is usually given in /etc/pam.d/smtp and is beyond the scope of this document. 

Kopano is not installed at this point - the error message comes from the SMTP server test message (using 587/TLS); the postfix config files are nearly identical (given the necessary changes between v2.6 and v2.10 .. the only difference in the SMTP notification settings is that the 6 box is set to SSL and the 7 to TLS (acceptable as TLS superceded SSL)

Full log from the 7 box;

May  7 10:02:00 sark postfix/smtpd[5097]: connect from localhost[127.0.0.1]

May  7 10:02:00 sark postfix/smtpd[5097]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

May  7 10:02:00 sark postfix/smtpd[5097]: warning: SASL authentication failure: Couldn't find mech CRAM-MD5

May  7 10:02:00 sark postfix/smtpd[5097]: warning: localhost[127.0.0.1]: SASL CRAM-MD5 authentication failed: no mechanism available

May  7 10:02:00 sark postfix/smtpd[5097]: 7E17D40C6017: client=localhost[127.0.0.1], sasl_method=LOGIN, sasl_username=xxxxxxx@xxxxxxx.xx.xx

May  7 10:02:00 sark postfix/cleanup[5101]: 7E17D40C6017: message-id=<20190507090200.4704.1355685497.swift@xxxx.xxxxxxx.xx.xx>

May  7 10:02:00 sark postfix/qmgr[3771]: 7E17D40C6017: from=<xxxxxxx@xxxxxxx.xx.xx>, size=654, nrcpt=1 (queue active)

May  7 10:02:00 sark postfix/smtpd[5097]: disconnect from localhost[127.0.0.1]

Here's exactly the same from the 6 box; note the lack of error

May  7 09:54:47 neotrantor postfix/smtpd[15204]: connect from localhost[127.0.0.1]

May  7 09:54:47 neotrantor postfix/smtpd[15204]: setting up TLS connection from localhost[127.0.0.1]

May  7 09:54:47 neotrantor postfix/smtpd[15204]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

May  7 09:54:48 neotrantor postfix/smtpd[15204]: 1065C341E5D: client=localhost[127.0.0.1], sasl_method=LOGIN, sasl_username=xxxxxxx@xxxxxxx.xx.xx

May  7 09:54:48 neotrantor postfix/cleanup[18817]: 1065C341E5D: message-id=<20190507085448.11311.83334475.swift@xxxxxxxxxx.xxxxxxx.xx.xx>

May  7 09:54:48 neotrantor postfix/qmgr[19560]: 1065C341E5D: from=<xxxxxxx@xxxxxxx.xx.xx>, size=637, nrcpt=1 (queue active)

May  7 09:54:48 neotrantor postfix/smtpd[15204]: disconnect from localhost[127.0.0.1]

Unless I've misunderstood what the error message and that postfix entry says, it would appear that authentication is working on the 6 box, but failing on the 7 box (even though the test message goes through), so either the 6 box is using an MD5 from some unknown source, or there's hidden changes - either in Postfix itself, or in the changes between 6 & 7.

Oh and saslauthd on the 7 box ..

SOCKETDIR=/run/saslauthd

MECH=pam

FLAGS=

and the 6 box ..

SOCKETDIR=/var/run/saslauthd

MECH=pam

FLAGS=

.. just the change of location - note the mechanisms are the same.

Maybe a more relevant question then is .. if the 6 box isn't using MD5, why is the 7 box trying to?

You could try diffing the full output of "postconf" from both boxes to see if any of the defaults have changed. Otherwise just diff the output of "postconf -n" but I think you've done that visually.