Jorey, thanks for your email also. Sorry for the delay, but you and
Barney have been hugely instrumental in getting me on track with this.
On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote:
Scott Haneda wrote, at 04/24/2009 07:41 PM:
Thanks for this, this is getting me on track, comments interspersed
below...
On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote:
Scott Haneda wrote, at 04/24/2009 07:58 AM:
For port 587 submission, I want to offer SSL, TLS, and non
encrypted to
cover the users who will not want to change their settings.
Use:
-o smtpd_tls_security_level=may
-o smtpd_tls_auth_only=no
I think it's normally a bad idea not to enforce TLS on the
submission
port, but if you're using a secure mechanism and want to prevent
weaker
ones, add:
-o smtpd_sasl_security_options=noanonymous,noplaintext
-o smtpd_sasl_tls_security_options=noanonymous
If you do not like a lack of TLS enforcement on the submission port
what
do you suggest for users who just do not care enough to use any TLS?
I suggest they use it if they want to send mail. :)
Since one of the purposes of the submission port is to support road
warriors, I feel it should be as secure as possible and the entire
communication should be encrypted.
I am in a bad spot in this regard, because of some of the faults of my
current email server. It is pushed a bit to move users to 587, but
the server does not support SSL/TLS. It would be very hard for me to
get them to all change their settings to use SSL/TLS. I would love to
make 587 the default secure port, I just do not thing I can put my
users in that situation.
If postfix can log in a way that I can tell what is going on, and over
time, I can make a call a day, and convert people over to TLS,
eventually I will flip this switch.
You let them work on port 25?
In some cases, I allow the use of a secure mechanism without TLS on
port
25. This protects the login, but not the message contents. I don't
allow
unencrypted plaintext logins.
I am leaning back on this idea again. Have to hash that out from the
standpoint of a proxy. I am just do not know if I gain anything by
putting all user MUA traffic on a non port 25 port. I know the proxy
tries to learn from users sending emails, and white list the
recipients, I do not know if that learning is port bound or not.
Glad you brought up webmail. I am going to use Roundcube, on the
same
machine, worst case, on a close machine, in the same subnet. Since I
have the nynetworks setting set to allow mail, all should be ok? I
do
not want to deal with AUTH for SMTP in webmail, it is going to be
local
to local, I see no point in securing that part. Is that correct?
It's up to you. I use SMTP AUTH for webmail, partly because it
provides
better logging for troubleshooting.
Good point. What webmail are you using? Does it globally SMTP AUTH
via a config file and a smtp account, or is each user login it's own
SMTP AUTH case, which is where you are picking up the logging data
specific to the sender under that specific account?
I am confused about your comments about 465. Reading it makes me
think
that 465 is sort of a last resort option. I am not understanding the
difference between SSL and TLS. If I was setting up a email
client, and
could use TLS versus SSL, my logic would be to use SSL, it seems the
better option, but I do not know why.
Are you saying SSL email is the lesser of the options, and I should
use
TLS when I can?
I'm saying that smtps (wrapper mode on port 465) is deprecated in
favor
of STARTTLS on ports 25 or 587.
Good to know. For some reason, SSL sounds the better way to go in my
head, and in the heads of a lot of people I talk to. Strange, because
when I think about it, how it sends out a STARTTLS, and moves on from
there, that seems a better policy, less prone to problems as well.
Do you know how this related to Apple Mail? There is no setting in
the
SMTP section to opt for SSL versus TLS? "Use SSL" is the only
checkbox
there is. I take it if you do not select that, it will use TLS if it
can, but do so in a invisible way?
Default autoconfiguration appears to use ports 25, 465, & 587 and
SSL if
detected. The server I tested supports all of these and the mechanism
list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration,
Apple
Mail used STARTTLS and the PLAIN mechanism on port 25 to send a
message.
Are there are good reasons to support PLAIN and LOGIN and PASSWORD? I
have told all our users to use MD5 Challenge Response. Maybe I would
aid Apple Mail in figuring out which to pick, it seems to always fall
back on PASSWORD iirc. Perhaps other desktop clients do not support
md5 mechanisms.
I assume it follows an algorithm to determine a fallback strategy for
trying the other ports if its first choice is not available.
Although I
would have preferred it start with port 587, the choice it made is
acceptably secure. If you only offer port 587, it probably won't pose
any problems (as long as it remembers the other ports are
unavailable).
A friend of mine signed up for some cheapo hosting account, and they
had a apple script to set it up. It did not work, but I have been
meaning to swipe it and fix it. It looks very simple to deal with,
and you can shove the users login name in, so all they do is run it,
connect to get email, enter in their password, and click "remember"
and they are done.
I would bet I can alter the default port in this script as well.
It probably is this setting that has lead me down the road of
thinking
SSL is better, as Apple Mail offers what appears to be no
encryption, or
SSL, there is no implicit TLS setting.
Looking at Outlook settings:
http://www.math.uwaterloo.ca/mfcf/announcements/images/outlook2.png
It appears in the same case, SSL is going to be selected, as the
better
way, I see no way to use TLS. Maybe I am not groking any of this,
any
brief explanation of this sure would help.
Don't make assumptions based on the nonstandardized vocabulary found
in
MUAs. In this context, "SSL" is meaningless and interchangeable with
"TLS" (technically, SSL evolved into TLS). STARTTLS is preferable to
smtps (SSL wrapper mode on port 465). But if you need to support
smtps
for legacy clients, go ahead.
Thanks, that explains where some of my confusion comes from, in that
the terms are interchangeable in some contexts.
In any case, it's good practice to check this box if the server
supports
secure mechanisms, for a little extra protection beyond SSL/TLS.
What more do I need to do in postfix cf files to support this
setting?
Any downsides as far as performance and load?
You'll have to refer to your SASL implementation to see what
mechanisms
you can support. There can be some additional overhead with the secure
mechanisms, but it's nice to have the flexibility. Also, some MUAs
behaved unpredictably when certain mechanisms were absent as
autoconfiguration was being developed. This is less of an issue,
now. To
be honest, PLAIN w/STARTTLS is usually adequate, and is universally
supported in MUAs.
Ok, but to be clear, on a AUTH only, no crypto account, you would not
want to use PLAIN, but something like md5?
Curious, why is NTLM an option I see often, I am yet to see a MUA
client support it, other than showing it. I can never get it to work.
What are the real pros and cons of each of the 7 or so AUTH mechanisms?
When it comes to a TLS or even an SSL connection, I take it at that
point, the AUTH mechanism you chose really makes no difference? Is
there a performance hit, where it would be more ideal to use a less
complex mechanism since you are TLS'ing the entire channel anyway?
smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
If you're not using client certificate authentication (and you
probably
aren't), delete those lines.
Well now you threw me for a loop :) I am a small ISP, and I will
buy a
emailserver.company.example.com SSL cert. As it is now, in email
clients, I get a box pop up asking me to approve my current self
signed
one as a non known untrusted authority. I just select accept
always and
move on.
So removing those certs above just removes the certificate trust
issue,
but does not change any of the encryption methods I have going on?
In
apache, I can not enable SSL, as far as I know, without a cert. I
was
under the impression, if I want to offer SSL, I am going to need
those
certs?
No, you're thinking of smtpd_tls_*_file, which you still need. I'm
suggesting you might not need smtp_tls_*_file, which is used when
postfix is the client to other systems.
Slowly beginning to grasp this, thanks for the *'s, this is making a
lot more sense.
Thanks again, see my one previous email if you need a postconf dump
for any reason.
--
Scott * If you contact me off list replace talklists@ with scott@ *
