On May 1, 2009, at 7:19 AM, Jorey Bump wrote:
Scott Haneda wrote, at 04/30/2009 10:11 PM:
What happens is, under heavy MTA load on port 25, I will run out of
connection slots on port 25.
Have you investigated the nature of this problem?
Thoroughly. My current email server lacks control, it is only recently
we have even been given greylisting. Moving users to port 587 largely
solved it, but issues still remain. It is just time for me to move
on. I am at the whim of the developer, this is not a config file
driven email server. Even mention of SPF on his mail list get you
told to not talk about it. It is not an option, and while I
personally do not intend to use SPF, I want options, which postfix has
abound.
To be honest, I have received more education and support from you and
a few other people on this list in a few days than the 10 years of
using something else.
I do thank you all again, as well as those who make postfix what it is.
By moving users to 587, I do not care
about port 25 connection slots. MTA's will try again later if busy.
You might be chasing a red herring. If your server is overloaded,
there
is a reason why, and there may be more effective remediation
techniques
available. Improving your submission service is good, but it might not
deliver the performance payoff you're expecting.
You nailed it, there are indeed many more techniques for dealing with
my issues. Manually scanning logs and putting IP ranges into a local
DNS blacklist and manually creating rules that are not flexible in how
they can match patterns is what hinders me for the most part.
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.
If you still have a heavy load, consider separating your MX entirely
from submission, using separate instances/machines. It's generally
easier to move the MX, since MUA configurations don't care about it.
I have this as a option from the beginning of setup. I was given a
large enough IP allocation that I tend to give up an IP for each
service, and create DNS records pointing to each IP. If I ever need
to for example, most SMTP 587 to it's own machine, it is as simple as
just setting up the software, remove the old IP from the old machine,
and putting it into the new machine.
I use will use this when I migrate as well, not having to fiddle with
DNS TTL's and some other ISP's that seem to cache DNS and not honor
TTL's then becomes a non issue.
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.
FWIW, a poorly implemented proxy can do more harm than good. A lot of
sites just toss them in, and don't pay attention to finer details like
DNS settings and recipient validation.
I have spent the past few years looking at them and reading about
them. Starting with the hardware driven devices like Barracuda. My
main reason for not deploying as of yet was the only way to get user
validation on my server was LDAP, which I could not ever get to work
reliably. Maintaining a text file of users was an option, but at
minutes to dump a list of users via AppleScript from the email server,
I did not like that option.
I am settling in on ASSP, which seems to solve my needs, and provide
everything I need. If it turns out I do not like it, the nice thing
about a proxy is, you just turn it off, a quick change of port
listeners in postfix, and I should be back up and running.
# 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?
These are for all client connections that use STARTTLS, not just MUAs.
The difference is that MTAs typically don't quit if they can't verify
the cert (check it against a root certificate store), so using a
self-signed cert is adequate.
It is increasingly harder to support MUAs with noncommercial certs,
however. You can get basic ones fairly cheaply, so I recommend it to
avoid annoying warnings to your users.
I plan on getting one from a good provider. I have seen too many
cases where Safari balks at the 10.00 ones from GoDaddy, and it seems
hit or miss as to which ones they supply that will be an issue. I do
not mind paying a one time fee even if it is a little pricey, to gain
reliability.
# client TLS parameters, forward mail via TLS if possible
smtp_tls_security_level = may
I had this one already I believe.
This is what you need for your server to connect *as a client* to
other
MTAs, opportunistically using STARTTLS when offered.
In a previous sentence you used the word 'typically' in regards to if
the MTA will quit or not on seeing a cert. What is the risk here? If
I understand, this gives an opportunistic ability for MTA to MTA
discussion to be secure, falling back on the old plain method if it is
not available.
Is there really a lot of exploiting going on in-between one MTA and
another? From what I can tell, this would boil down to a rogue person
at some router between me and say, gmails servers, that wanted to
intercept traffic. Just does not seem likely.
Just curious, if you do not have time to explore this side of the
conversation, I understand.
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?
Don't set it up until you have everything else working properly (TLS,
submission, etc.). Then wait until you find a need for it. Normally,
the
Postfix defaults in master.cf will suffice (assuming your distribution
hasn't fiddled with them).
Ok, sounds like a solid plan. I mostly am supporting Mac users, and
can easily mimic the desktop clients they are using. On the windows
side, any open client should for the connection level, be able to be
tested on the Mac. As far as I know, this leaves me with Outlook.
There are countless versions of Outlook, I guess I will have to track
down a PC I can use, or a friend who can let me remote into one.
smtp_tls_session_cache_database =
btree:$data_directory/smtp_tls_session_cache
Keep if you need it.
I wish I knew where I picked up this setting. Reading the docs at ( http://www.postfix.org/postconf.5.html
) does not lead me to an answer as to whether I need it or not.
Where can I find out more about this and what the pros and cons are?
smtpd_sasl_security_options = noanonymous
Change to noanonymous, noplaintext if you don't want passwords sent in
the clear.
If I set this to noanonymous, noplaintext to confirm, if any of my
current users are using an authenticated plain text login method, they
would fail to login?
This then gets my phone ringing, where I can help them make the
changes to either use a non plain text login method, with auth, or use
a plain style login with crypto. I think I have that correct.
smtpd_tls_ask_ccert = yes
Why?
I wish I knew, removed, letting it use default of no.
smtpd_tls_session_cache_database =
btree:$data_directory/smtpd_tls_session_cache
Keep if you need it.
Same here as the other cache entry, not able to really find why I want
it or do not want it for my configuration.
tls_random_source = dev:/dev/urandom
Probably the default.
My default as per postconf -d is empty.
It's generally a good thing, because /dev/urandom
is nonblocking. Some systems might use /dev/random, which blocks and
can
hurt performance in low entropy environments (opinion on security
implications is mixed).
That exactly why I chose this one, urandom, I read the wiki page on
it, and though there is less entropy than /dev/random I liked the fact
that calls were not blocked.
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
IMHO, too weak for port 587.
Can we explore your HO on this. I have helped many a friend set up
email for any number of the 9.99 a month ISP's out there, the are all
offering normal 25, some alt submission port, and some SSL port as
well. I am yet to see any particular mandate that the submission port
be crypto mandated. Not that I want to just follow the examples set
by others, as often is the case, they are "doing it wrong" anyway.
I am just not seeing why a user can not auth with no crypto. Or, are
you taking the stance that users really do not know about this stuff,
and it would be best if you protect their actions on their behalf?
I certainly can appreciate that. Having to deal with hundreds of
iPhone users, and desktop users, when I toggle this switch may prove
less than fun. Since my old server does not support SSL/TLS, it is
not like I can send an email out, tell them to switch, and then mass
move everyone to postfix. This is going to be a throw the switch, and
start answering phone calls.
I do really like the idea of all users being secure. Perhaps I will
set up a new MX, run the old and the new at the same time, and migrate
one domain at a time, that would remove the "throw the switch" support
burden.
Not really liking the idea of using a new domain for setting up the
postifx server. I am pretty sure I can not do this in the same
domain, as the second I add in a MX pointing to the new postfix
server, that is going to break everything.
465 inet n - n -
- smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated
Don't use smtps port 465 unless you need it.
Ok, I am going to comment that out, get my hands on as many email
clients as I can, and start running some tests.
Here's an example from one of my servers:
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
What specifically about smtps was it that you ended up determining you
needed it?
I can not thank you enough for all your time. Have a good weekend.
--
Scott * If you contact me off list replace talklists@ with scott@ *
