On 3/22/19 7:01 PM, Dave Warren wrote:
To me, the big one is this: It sets your users up for failure. If a user configures their client on a network that allows unrestricted port 25 access and later moves (temporarily or permanently) to a network that does restrict port 25, they'll get an error and you'll get a support ticket.
Valid as that is, that is addressing a client issue, not a server issue.
You'll save yourself a lot of hassle if you get clients set up right from the start rather than fixing user configurations after the fact.
Agreed. But configuring clients to use port 587 or 465 does not preclude allowing SMTP Authentication on port 25.
One other consideration, although this is more opinion than fact: In my experience users/clients that still default to port 25 often don't default to STARTTLS and therefore will transmit an unencrypted password at least once (even if you refuse it and instruct them to authenticate, the damage could already have been done). Forcing 465 is the only way to ensure that this can't happen, but clients that default to 587 are far more likely to default to using encryption.
There is another way. You can configure the server to not offer SMTP Authentication until after encryption is established with STARTTLS.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
