On Wed, Jul 05, 2023 at 10:09:12PM +0200, Ede Wolf via Postfix-users wrote:

> thanks very much for your reply. I still may have some understanding issues:
> 
> Am 05.07.23 um 16:22 schrieb Viktor Dukhovni via Postfix-users:
> > On Wed, Jul 05, 2023 at 02:42:54PM +0200, Ede Wolf via Postfix-users wrote:
> > 
> >> I am having a weired issue. My provider for the relayhost switched to
> >> SSL - which is fine by itself - but that also changed the authentication
> >> scheme.
> > 
> > What SASL mechanism was used before that?  
> 
> Frankly, I do not know, it just worked with the posted configuration.

You answer this below.

> > likely progress.  As is enabling TLS, regardless of whether the SASL
> > mechanism is challenge-response based.
> 
> Thanks for the heads up. According to the support, they now do store the 
> hash.

Presumably *only* the hash, with the cleartext passwords not stored.
Otherwise, the result is less secure.

> > That's not quite the whole story, the relevant documented defaults are:
> > 
> >      smtp_sasl_security_options (default: noplaintext, noanonymous)
> >      smtp_sasl_tls_security_options (default: $smtp_sasl_security_options)
> >      smtp_sasl_tls_verified_security_options (default: 
> > $smtp_sasl_tls_security_options)
> > 
> > But you need at least the last of these to admit "plaintext" (i.e. not
> > specify "noplaintext").  The correct (security-minded) configuration is:
> > 
> >      # smtp_sasl_security_options = noplaintext noanonymous
> >      # smtp_sasl_tls_security_options = $smtp_sasl_security_options
> >      smtp_sasl_tls_verified_security_options = noanonymous
> 
> Not sure I am understanding this correctly. While commented out in my 
> above example, I have been using:
> 
> smtp_sasl_security_options = noanonymous

You should if possible change just:

> >      smtp_sasl_tls_verified_security_options = noanonymous

and make sure that the connection to the is "verified" (TLS security
level "secure").

> before, and it did not work, that is why I removed the noanonymous. 
> However, now I have tried both:
> 
> smtp_sasl_tls_verified_security_options = noanonymous
> 
> and:
> 
> smtp_sasl_tls_security_options = noanonymous

See below, with the critical additional detail you present now (and
sadly did not know to present before), there's more to be done.

> and all three of them. Again, I do not comprehend, how noanymous forces 
> PLAIN.

It doesn't "force" PLAIN, it *unblocks* PLAIN, but other offered
mechanisms will be considered, and may be preferred.

> Anyway, there is no difference at all, mail is being rejected.

As expected see below.

> > Use a custom "default_transport" with an explicit "nexthop" relay,
> > instead of just "relayhost".  This makes it possible to specify
> > appropriate TLS policy settings without resorting to a TLS policy table.
> > 
> >      main.cf:
> >          # Possibly with a ":port" suffix
> >          default_transport = isprelay:[smtp.provider.net]
> > 
> >      master.cf:
> >          # Note, no chroot!
> >          isprelay   unix  -       -       n       -       -       smtp
> >              -o { smtp_tls_security_level = secure }
> >              -o { smtp_tls_CAfile = /etc/postfix/ispcas.pem }
> > 
> > The "ispcas.pem" file (or pick another pathname) can list just the CAs
> > you trust and expect to issue the ISPs certificate (ideally less than
> > the entire browser CA/B forum CA "bundle").
> > 
> 
> What advantages may this have to simply specifying:
> 
> smtp_tls_security_level = encrypt

The latter is not authenticated, so an MITM could "steal" your password.

> The Server advertises:
> 
> EHLO nebelschwaden.de
> ....
> 00d0 - 90 ee e2 1b 4b 
> 250-mail.worldserver.net
> 250-PIPELINING
> 250-SIZE 71303168
> 250-VRFY
> 250-ETRN
> 250-AUTH PLAIN LOGIN CRAM-MD5
> 250-AUTH=PLAIN LOGIN CRAM-MD5
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 CHUNKING
> 
> The problem here is, that the annoucement of CRAM-MD5 is false. While it 
> still does work for older accounts, it does not any more not for newly 
> created or somehow modified older ones.

BINGO!  The server is advertising CRAM-MD5, and unless you filter it out
SASL will attempt to use that instead of plain.  Therefore, in the
proposed "master.cf" entry you also need:

    -o { smtp_sasl_mechanism_filter = plain }

See: https://www.postfix.org/postconf.5.html#smtp_sasl_mechanism_filter

> So probably, to answer your initial question, I do suppose I have been 
> using cram-md5 until now. Now I need to force (not just admit) plain 
> and, unless I have missed something, the smtp_tls* settings are not enough.

Correct, see above.  Ideally you'd have known to share this new
information, but if you had known it to be important, you might
have solved the problem without outside help, or been close to
doing so...

That said, generally oversharing possibly relevant technical details is
generally a safe bet.

-- 
    Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to