Here I am, replying to my own post again. What I said in the prior post wasn't entirely true. I realized that I used the wrong password in my prior attempt. I am still granted access to the SMTP service after authenticating in plaintext on port 25.
So I'm somewhat confused how to prevent/discourage users from sending their authentication detail in the clear when there are secure methods that exist (such as, $ openssl s_client -starttls smtp -connect example.com:587) $ telnet example.com 25 Trying 87.138.xxx.yyy... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Postfix (Ubuntu) ehlo example.com 250-example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH LOGIN 334 VXNlcm5hbWU6 dXNlckBleGFtcGxlLmNvbQ== 334 UGFzc3dvcmQ6 eW91IHdvdWxkIGRlY29kZSB0aGlz 235 2.7.0 Authentication successful quit Thanks On 12/3/2016 at 10:03 AM, rich.gre...@hushmail.com wrote: > >I suspected that was a typo. I figured it out. > >I made those changes, when I attempt an AUTH LOGIN, I get back >"535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6" which seems >to be appropriate. > >So the user is no longer rewarded with access to the SMTP services >when they attempt to connect using this method, such as sending a >plaintext password on port 25. Obviously, user irresponsibility >can't be prevented, but at least they are denied access for >attempting to connect in an irresponsible manner. So yes, I can >see how this works. > >Thanks > >On 12/3/2016 at 9:49 AM, "Wietse Venema" <wie...@porcupine.org> >wrote: >> >>John Fawcett: >>> On 12/03/2016 04:10 PM, Wietse Venema wrote: >>> > rich.gre...@hushmail.com: >>> >> There are ports that exist for encrypted transfer of this >data >>> >> (such as 465, 587). What is the current state of the art for >>> >> preventing the user's client software from being able to do >>this >>> >> (sending their authentication details plaintext)? Is it >safe >>to >>> >> simply block this port external to the machine, for example, >>in >>> >> the router? >>> > Don't enable SASL auth on port 25. >>> > >>> > Do require smtpd_tls_auth_only=yes on port 587. >>> > >>> > This is easiest implemented by seting smtpd_sasl_auth_enable >>and >>> > smtpd_tls_auth_only in the master.cf entry for the port 587 >>service, >>> > and not setting them in main.cf. >>> > >>> > submission inet n - n - - smtpd >>> > -o syslog_name=postfix/submission >>> > -o smtpd_tls_security_level=encrypt >>> > -o smtpd_sasl_auth_enable=yes >>> > -o smtpd_sasl_auth_only=yes >>> > -o smtpd_reject_unlisted_recipient=no >>> > -o smtpd_client_restrictions=$mua_client_restrictions >>> > -o smtpd_helo_restrictions=$mua_helo_restrictions >>> > -o smtpd_sender_restrictions=$mua_sender_restrictions >>> > -o smtpd_recipient_restrictions= >>> > -o smtpd_relay_restrictions=permit_sasl_authenticated,reject >>> > -o milter_macro_daemon_name=ORIGINATING >>> > >>> > (similar for the obsolete 'smtps' service on port 465). >>> > >>> > mua_client_restrictions, mua_helo_restrictions, >>mua_sender_restrictions >>> > can then be specified in main.cf. >>> > >>> > Wietse >>> >>> Wietse >>> >>> this looks like a typo >>> >>> -o smtpd_sasl_auth_only=yes >>> >>> that should be >>> >>> -o smtpd_tls_auth_only=yes >>> >>> in line with your comment above the config. >> >>Yes. >> >> Wietse
