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:
>>
>>> I am a little confused about main.cf and master.cf.  Is there overlap in
>>> some of the settings? Do some settings exist in both files, or at least
>>> are interchangable?  If this is the case, under what conditions do you
>>> decide to do so?
>>
>> From master(5) [http://www.postfix.org/master.5.html]:
>>
>> -o name=value
>>       Override  the  named  main.cf  configuration
>>       parameter. The parameter value can refer  to
>>       other parameters as $name etc., just like in
>>       main.cf.  See postconf(5) for syntax.
>>
>> As implied, it's useful when you need to override the settings in
>> main.cf to get different behaviour appropriate to the service you're
>> setting up in master.cf (submission, reinjection from proxy/filter,
>> etc.).
> 
> I have a little affliction against man type pages, they never seem to
> make a lot of sense to me :)  This section does though.  Just to be
> clear, this is a full blown over-ride, in that deleting the
> corresponding value from main.cf would do nothing to the server, so long
> as it exists in master.cf?

Yes. But keep in mind that most settings have a default value. It's
healthy to define a base configuration in main.cf, where your needs
differ from the defaults, then only apply overrides in master.cf where
necessary.

>>> 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.

> 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 could go that route, but I am really
> trying to find a way to do traffic isolation.  If I know no client
> connections are made on 25, from a troubleshooting perspective alone, it
> seems to make things simpler on me.

I think it's reasonable. Just give your users advance notice so they can
change their settings.

> 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.

> 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.

> So the ideal situation is using TLS on a non 25 submission port?

Ideally, STARTTLS on the standardized submission port 587.

> 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.

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).

In any case, you can set the port & mechanism explicitly, and it will
negotiate TLS/SSL appropriately for either wrapper mode or STARTTLS.

> 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.

>> Thunderbird has a "Use secure authentication" checkbox that supports
>> multiple mechanisms (independent of SSL/TLS). Unfortunately, *it*
>> decides which one to use, which I find very frustrating.
> 
> I am glad you brought up "Use secure authentication", what exactly does
> this setting do?  In Thunderbird, there is none, optional TLS, and SSL,
> and then this "use secure auth" setting.  That is a lot of control, and
> totally unclear on what setting in postfix that secure auth checkbox is
> going to run up against.

Sorry, my bad. "Use secure authentication" is only displayed in the
Server Settings area, which applies to POP/IMAP. Still, Thunderbird will
use secure mechanisms if available for SMTP. For example, if you have
active kerberos tickets for the SMTP server, I believe it will use them
for authentication. IIRC, there's a lot of imperfect magic that goes on
behind the scenes, and some room for improvement. It's especially
important to only offer mechanisms you actually support.

> Apple Mail does not even have such a setting, so I assume it is one of
> the encryption modes that kicks it in?

Apple Mail lets you specify which mechanism to use. During
autoconfiguration, it will choose from the list your server advertises.
 Note that this list may differ depending on the presence of encryption.
Apple Mail appears to negotiate encryption if available, then choose
from the advertised list.

>> 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.

>>> 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.

> In my context of using Dovecot, and not using the cyrus sasl thingy,
> where I see mention of _sasl_ in a config line, that is in reference to
> both SSL and TLS?

No. SASL is not SSL/TLS.


Reply via email to