Barney, ( and Jorey ), thanks so much for your help in understanding
this, moving to postfix is something I have needed to do for some
time, glad to finally get down to it. I had to step away for a few
days and get some other work done, but made some good progress last
night. I have some more clarifications thought if you do not mind.
On Apr 24, 2009, at 9:35 PM, Barney Desmond wrote:
2009/4/25 Scott Haneda <talkli...@newgeo.com>:
If you do not like a lack of TLS enforcement on the submission port
what do
[snip... on SSL/TLS methods]
think most are on 587 as a result of most ISP's filtering 25.
There's a few distinct concepts here:
[snip... Explanation of SSL/TLS]
I am hesitant to detract and add more to this, but here goes. My
current email server does not support SSL/TLS. I have 250-AUTH CRAM-
MD5 DIGEST-MD5 NTLM PLAIN LOGIN
( Does the order of my methods matter? )
I do have some auth methods in regards to the user/pass, but from what
I understand, the data is always in the clear. My current setup is
*mostly* MTA to MTA on port 25, there are a handful of users whose
ISP's have not filtered 25, so those users are still on port 25.
I can force auth on 25, but with no way of testing that before
toggling the setting, I am not anxious to do so. tcpdump would be the
only way, and a little too much of a pain to deal with.
The reason I want to force all users to 587, and allow auth and crypto
on 587, and not mandate crypto exclusive, is that is how 99% of my
users are set now, 587 using md5-challenge response.
This has been done at suggestion of the developer of my current
server. What happens is, under heavy MTA load on port 25, I will run
out of connection slots on port 25. By moving users to 587, I do not
care about port 25 connection slots. MTA's will try again later if
busy.
What I do not want, is MUA users getting a server busy response on
port 25 just because mail volume is high that day. The general
suggested idea from the developer of my mail server is to move all
users to port 587, and only have MTA mail on port 25.
Hopefully this issue of running out of connections is not much an
issue in postfix. I also have a setting of "limit x connections from
same host". If I have an office of users, logging in over a LAN,
where their public IP is a fixed IP, and they all have private IP's,
my current mail server sees them all as many connections from the same
IP, and they get too many simultaneous connections errors. ( How does
postfix deal with this? )
Because of this, I can not limit connections from same host on port 25
to a reasonable number to slow dictionary attacks and the like, as the
office of 100 employees is going to hit a wall really soon.
By moving them to 587, I have more control.
Maybe I am just jaded in how my old email server forced me down a
path, and I should not worry about this, and allow 25 and 587 to
behave identical, with one exception in that 587 would disallow
explicitly any non authenticated connections.
I think I can force auth and crypto on 587 and not hassle my MUA users
one bit; then allow auth no crypto on 25, and also open it to non auth
non crypto for MTA chatting. Not sure if that is possible, to allow
non auth MTA mail on 25, but also tell MUA clients they must at
minimum, auth.
What do you guys think?
My end goal here is to get this all working, and then change these
ports to, for example, 25 -> 2525 and 587 -> 587587 unless there is
some other convention. I am going to put a anti spam proxy in front
of all this.
I just do not want to add too much to my learning curve, so first, get
postfix to where I understand it, then toggle the ports and put the
proxy in. It should blindly pass the traffic, I assume in much the
same way stunnel does.
I am open to any and all advice on this matter to make this work
best. I have a feeling later on down the road I will need to learn
exactly what things to disable in postfix, as it should not do any
bouncing at all, anything that will lead to backsplatter, since I am
putting a proxy ahead of it.
2. The alternative is to wrap everything in a crypto pipe - this is
SSL or TLS. Once the whole session is encrypted we don't care how
authentication happens, as confidentiality is provided externally.
It's obvious that there's a 2x2 matrix of auth+crypto options here. If
you're trying to be very flexible then you're probably interested in
stopping the one possibility that could leak passwords - no-crypto
while using insecure auth.
Correct. I was actually not aware that something like password, md5-*
etc was even a legitimate way of protecting yourself. I understand
the data channel is plain text, but the user and pass being hashed in
some way, I had assumed it would be trivial to crack, something akin
to base64. Good to know it is a lot more than that.
I'm happy for
mail clients to select the best mechanisms available for easy
autoconfiguration, but it would be nice to have the ability to set
them
explicitly (for troubleshooting or security reasons).
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?
This depends on what you want your security policy to be. One useful
main.cf option is smtpd_tls_auth_only - when TLS is optional, it'll
only offer authentication if the connection is encrypted. (obviously
it's always safe to offer authentication if encryption is mandatory).
The catch is that authentication isn't strictly handled by postfix.
Your SASL backend (cyrus or dovecot) specifies what authentication
protocols are offered; I believe this is because it's the SASL daemon
that has to deal with the password backend, so it's the right place
for that sort of policy. You can't offer CRAM-MD5 if the passwords are
stored in a hashed form; postfix has no knowledge of the password
storage, so authentication can't be handled in postfix (though sasl
can be tweaked a little).
I have been playing with smtpd_tls_auth_only to ill results. I have
no setting in main.cf now, meaning it is defaulting to
smtpd_tls_auth_only = no
If I understand the docs:
"When TLS encryption is optional in the Postfix SMTP server, do
not announce or accept
SASL authentication over unencrypted connections."
I think I want this to "no" anyway, is that correct given my end goals
here? Or maybe I want this as "yes", and then over ride certain parts
in the master.cf?
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?
Correct, a paid-for cert will sidestep the trust issue for your users.
It's the same here as it is in apache. Crypto certs are just "dumb
data" - it's primarily key material, it doesn't affect how your crypto
works, or how strong it is, etc.
Interesting, good to know. I have been mistaken then, in that I
thought the cert itself provided the public and private keys, that
were used as a basis for the encryption, sort of like a salt. Is what
you are saying is these just prove identity and trust, but do not in
any way create encryption?
I think you misinterpreted that comment though. "If you're not using
client certificate authentication, delete those lines". What was meant
was, "if postfix isn't using certificates to authenticate ITSELF to
other servers, delete these lines".
I am still not entirely clear. The docs:
I am still not entirely clear. The docs: "Do not configure client
certificates unless you must present client TLS certificates to
one or
more servers. Client certificates are not usually needed, and
can cause
problems in configurations that work well without them. The
recommended
setting is to let the defaults stand"
That supports your statement. What is confusing, is most of the
tutorials for setting up Postfix have a section on setting these up.
Indeed, the ones I set up used a specific host name, and when I smtp,
or pop or imap, I am asked to authorize the self signed cert, as at
this time I do not have a purchased cert from a CA.
This tells me it is working on the MUA level. But are you also
saying, inbound SMTP connections from other MUA's also have to get
past these certs as well? And that a inbound server will depend on
their configs if they are to accept self-signed ones, and may even
have issues with genuine CA based ones as well?
What is the correct way to not use certs for MTA's, but to present one
to the MUA?
Perhaps I should just do as you say, which is not provide any cert. I
doubt a single one of my users wants to deal with them. Is it correct
they are gaining nothing other than proof I am who I say I am? SSL
and TLS will continue to work if I comment out those two lines?
Postfix can talk to other MTAs
with crypto as well, this is the `smtp_tls_security_level` setting -
notice the "smtp_" prefix on the config options, it's not "smtpd_".
So if I remove the two above cert lines, then smtp_tls_security_level
which I have set to "may", no longer needs to be set, and could sit on
the default, or set to none? This is a setting for inbound and
possibly outbound MTA traffic, basic non auth'd port 25 stuff, this
gives the ability to 'credentialize' that traffic, but is not easily
supported?
The thing is, you can do crypto with or without certs. A cert is just
a combination of (optionally) signed identify data tied to key
material. If you don't care about identities (and for MTA-to-MTA
traffic on the public internet, we don't), you can negotiate an
anonymous TLS session and everything works as you expect it should. By
setting smtp_tls_cert_file (I think) you're telling postfix to
negotiate a non-anonymous TLS session, which the other end may baulk
on if it doesn't have a cert, or can't verify your cert's signer, or
for any number of reasons.
I think I more or less reiterated what you are saying. Thanks. If
there are any other points of clarification, I would appreciate them.
smtpd_sasl_authenticated_header = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
I'd probably leave these in main.cf, just to keep master.cf
simple, but
it's your choice. Also, you can probably drop
smtpd_sasl_exceptions_networks, as it won't make sense if you
disable
SMTP AUTH on port 25 and require authentication on port 587.
I agree with this suggestion. You can keep sane settings in main.cf,
it's nicer to leave master.cf alone. You also *probably* don't need to
define smtpd_sasl_exceptions_networks.
I took out smtpd_sasl_exceptions_networks and let it fall on the
defaults to no ill effects, thanks.
An example from my config, if it helps.
# we can allow relaying by forcing senders to authenticate first (by
permit_sasl_authenticated in smtpd_recipient_restrictions)
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous <-- this is the default,
BTW
smtpd_tls_security_level = may <-- offer but don't require TLS
broken_sasl_auth_clients = yes
Thanks, I have some minor diffs, since my initial plan was to be more
strict about port 25. However, depending on what I learn from new
dialogue, this may change.
# server TLS parameters
smtpd_tls_key_file = /etc/ssl/yoshino.meidokon.net_key
smtpd_tls_cert_file = /etc/ssl/yoshino.meidokon.net_crt
smtpd_tls_auth_only = yes <-- as mentioned, user can only auth on a
secure connection
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
You have the two cert, ahhh, smtp*d*. Ok, I think I get it, that is
for MUA traffic, and you present them a cert authorization when they
are auth'ing. So I can even use the current certs I have in place now?
# client TLS parameters, forward mail via TLS if possible
smtp_tls_security_level = may
I had this one already I believe.
These parameters will apply to all smtpd processes
(smtp,smtps,submission) in master.cf unless you override the specific
settings there. You may choose to enforce crypto on port 587 with "-o
smtpd_tls_security_level=encrypt" but it's not technically necessary.
You'll usually add "-o smtpd_tls_wrappermode=yes" to the smtps
definition to get "SSL" mode working. I've personally got "-o
smtpd_client_restrictions=permit_sasl_authenticated,reject" for my
submission port.
The wrapper mode is probably a Outlook issue, or at least an older
buggy MUA client issue? I do not have any easy access to Outlook.
How do you go about testing before deployment?
Just in case:
alias_maps = hash:/opt/local/etc/postfix/aliases
biff = no
broken_sasl_auth_clients = yes
command_directory = /opt/local/sbin
config_directory = /opt/local/etc/postfix
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
disable_vrfy_command = yes
mail_owner = _postfix
mailq_path = /opt/local/bin/mailq
message_size_limit = 0
mydestination = $myhostname, localhost.$mydomain,
localhost
myhostname = catalyst.example.com
mynetworks = 64.84.37.0/26
newaliases_path = /opt/local/bin/newaliases
queue_directory = /opt/local/var/spool/postfix
readme_directory = /opt/local/share/postfix/readme
sample_directory = /opt/local/share/postfix/sample
sendmail_path = /opt/local/sbin/sendmail
setgid_group = _postdrop
smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
smtp_tls_key_file = /opt/local/etc/ssl/private/
dovecot.pem
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:$data_directory/
smtp_tls_session_cache
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated reject_unauth_destination permit
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_ask_ccert = yes
smtpd_tls_cert_file = /opt/local/etc/ssl/certs/postfix.pem
smtpd_tls_key_file = /opt/local/etc/ssl/private/
postfix.pem
smtpd_tls_loglevel = 0
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:$data_directory/
smtpd_tls_session_cache
tls_random_source = dev:/dev/urandom
virtual_alias_maps = mysql:/opt/local/etc/postfix/mysql-
virtual-alias-maps.cf,mysql:/opt/local/etc/postfix/mysql-email2email.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /opt/local/var/vmail
virtual_mailbox_domains = mysql:/opt/local/etc/postfix/mysql-
virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/opt/local/etc/postfix/mysql-
virtual-mailbox-maps.cf
virtual_minimum_uid = static:5000
virtual_transport = dovecot
virtual_uid_maps = static:5000
master.cf:
smtp inet n - n -
- smtpd
submission inet n - n -
- smtpd
-o smtpd_tls_security_level=may
-o smtpd_tls_auth_only=no
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated
465 inet n - n -
- smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated
pickup fifo n - n 60
1 pickup
cleanup unix n - n -
0 cleanup
qmgr fifo n - n 300
1 qmgr
tlsmgr unix - - n 1000?
1 tlsmgr
rewrite unix - - n -
- trivial-rewrite
bounce unix - - n -
0 bounce
defer unix - - n -
0 bounce
trace unix - - n -
0 bounce
verify unix - - n -
1 verify
flush unix n - n 1000?
0 flush
proxymap unix - - n -
- proxymap
proxywrite unix - - n -
1 proxymap
smtp unix - - n -
- smtp
relay unix - - n -
- smtp
-o smtp_fallback_relay=
showq unix n - n -
- showq
error unix - - n -
- error
retry unix - - n -
- error
discard unix - - n -
- discard
local unix - n n -
- local
virtual unix - n n -
- virtual
lmtp unix - - n -
- lmtp
anvil unix - - n -
1 anvil
scache unix - - n -
1 scache
dovecot unix - n n -
- pipe
flags=DRhu user=_vmail:_vmail argv=/opt/local/libexec/dovecot/
deliver -d ${recipient}
--
Scott * If you contact me off list replace talklists@ with scott@ *
