On May 1, 2009, at 6:30 AM, Jorey Bump wrote:
Scott Haneda wrote, at 04/30/2009 10:31 PM:>
On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote:
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 can alter the name syslog uses for the submission service by
adding:
-o syslog_name=postfix-submission
Nice, thanks.
Well, that's another potential advantage of using port 587: you can
spare authenticated users (and your system) from filter/proxy scans.
Glad you pointed that out, slipped my mind, but that is probably the
most compelling reason to get all users to port 587 for me at least.
Note that some environments still want to scan outgoing mail. Once
again, the fact that you're using an alternate port allows you to
customize settings to suit the purpose, so it can be another win.
Indeed, great point.
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 use SquirrelMail, which uses individual login credentials for both
IMAP access and SMTP AUTH. It's nice to have the user information in
the
logs. In fact, if you are using Roundcube, make sure it's fully
patched.
There is a vulnerability that is still being probed for daily against
likely locations for it on web servers.
Thanks for the heads up, I will make sure I am patched. I have been
using SM for years now, I just find it is too slow, and even with some
skins, is not what my users are after. I have a feeling the slowness
will be a non issues once I get dovecot talking to it. However, my
users rarely care about what is under the hood, and eat with their eyes.
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.
That's one option, but you might be better off going with the
autoconfiguration and providing instructions where that fails. Asking
users to run scripts is sending the wrong message, IMHO. It just makes
them more vulnerable to phishing and other exploits that rely on bad
practice.
I hear ya. Auto configuration is something Apple Mail only seems to
do. I have never seen it in other apps, though I have only personally
used Entourage. I use Thunderbird in testing now, and I do not see
any really slick auto conf in there either.
Let me put it this way, many times, my users can not enter in their
own email address, or will enter in a host name as m...@example.com
over mail.example.com, I know right away when I tell them to "get
mail" and do not see the connection come in.
I have learned the common mistakes they make, but even a auto
configuration still requires some data entry on their part. What I
would prefer is a simple xml or text file, that I could tell them to
import into a mail app, this could be universal, and have all the
settings in it, sans a password.
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?
Absolutely. Enforced TLS with PLAIN/LOGIN is often the best all-around
solution (total message encryption, low overhead authentication
mechanism). In that case, you can target TLS if you need to throw more
resources at it (increase entropy for the PRNG, hardware encryption,
etc.).
Thanks, makes good sense.
--
Scott * If you contact me off list replace talklists@ with scott@ *
