Nice description, Dan. Thanks.
I think it was Erik Espinoza who first informed me that the SMTPS
protocol is deprecated (the word is not depreciated), which is why the
stock QMT doesn't include configuration for port 465.
The qmail-smtpd man page says:
If the environment variable SMTPS is non-empty, qmail-smtpd starts a
TLS session (to support the deprecated SMTPS protocol, normally on port
465). Otherwise, qmail-smtpd offers the STARTTLS extension to ESMTP.
This describes SMTPS as being deprecated. I'm not sure what it takes for
a protocol to be officially deprecated if there is such a thing, but I
think it's safe to say that it is so.
Regarding the SMTPS variable, the man page indicates that it's use is in
conjunction with SMTPS on port 465, as Dan has indicated. I don't
believe though that the SMTPS variable can be used to force a client to
initiate a TLS session before authenticating, which would however be a
nice feature, as dovecot can do.
The problem here is that Gilbert's QMT appears to be requiring TLS to be
used on port 587. I don't know how that's possible. Unless if perhaps
Gilbert has the SMTPS environment variable set (to any non-empty value)
in his run file for port 587. There should be no such variable set
there. Maybe that's his problem.
--
-Eric 'shubes'
On 08/26/2011 05:13 PM, Dan McAllister wrote:
Please excuse me if I'm "Johnny Come Lately" on this -- and I'll admit
from the start that I haven't read the entire thread...
BUT... requiring SSL/TLS on an SMTP port (25, 587, or 465) is quite easy
in QMT... just edit the appropriate RUN file.
Also, the use of port 465 isn't really /depreciated/... but it is no
longer REQUIRED to use that port to use SSL. MANY sites (mine included)
use that port (and REQUIRE the use of SSL on that port) for external
(non-LAN-connected) clients to forward e-mail (that is: to send e-mail
from their internal mail account to an outside mail account).
In any case -- to the point:
The qmail-smtpd process looks for some environment variables to control
whether AUTH and/or SSL are utilized (forced). Remember, a separate
qmail-smptd process runs for each port.
REQUIRE_AUTH=1 forces anyone connecting on the listening port to use
authentication (username/password)
SMTPS=1 forces anyone connecting on the listening port to use SSL (by
default, SMTP allows SSL/TLS as an option -- this makes it mandatory)
Also of interest:
SPAMDYKE=1 forces messages to be sent through the SPAMDYKE filters (you
can say SPAMDYKE= <nothing> to turn OFF SpamDyke processing)
SPANDYKEFLAGS=<whatever> can be used to override the defaults set in the
spamdyke config folder. (for example: SPAMDYKEFLAGS="-f
/etc/spamdyke/spamdyke-for-validated-users.conf")
So... on my systems I generally have 3 qmail-smtpd processes listening:
1) Port 25 (standard smtp) is open to all and has REQUIRE_AUTH=0,
SMTPS=0, and SPAMDYKE set to its highest levels of detection
2) Port 587 (submission) is open only on the LAN and has REQUIRE_AUTH=1,
SMTPS=0, and SPAMDYLE set to a much lower level
3) Port 465 (SMTPS) is open to all and has REQUIRE_AUTH=1, SMTPS=1, and
SPAMDYKE set to the same lower level as 587
One final note -- in the run script, don't forget to EXPORT the
variables.... so its:
export SMTPS=1
-NOT just
SMTPS=1
Good luck!
Dan
IT4SOHO
On 8/26/2011 7:46 PM, Eric Shubert wrote:
On 08/26/2011 04:15 PM, Gilbert T. Gutierrez, Jr. wrote:
I have whitelisted my customer IPs so they can now send via port 25 if
they desire. My support staff were starting to get frazelled by all the
calls they were receiving. I do not assign rPTR records for most of my
customers and with the default settings of spamdyke those emails are
rejected.
I think I get the picture now.
FWIW, I configure servers to use authentication when sending emails in
order to avoid that problem. Plus I think it's a little more secure.
The submission port though seems to be requiring TLS according to what
my support techs (I don't talk directly to any of my customers anymore)
are telling me, and you are correct that it does not go through spamdyke
when using port 587. I am going to test at home and see if I can send
unencrypted. I have some customers that still have versions of Outlook
that do not support TLS.
TTBOMK dovecot (imap4,pop3) can be configured to require TLS/SSL, but
I don't know of a way to do so with the submission port 587, which
runs qmail-smtpd. Perhaps there's some confusion between the two?
FWIW, smtps (smtp over ssl, port 465, deprecated) is not configured on
the stock toaster. There are directions on the wiki regarding how to
set this up if you desire.
Outlook'03 and previous can use SSL but not TLS, ttbomk. Cram-MD5
might work in this case to keep passwords out of the clear, but I'm
not sure about that.
Gilbert
----- Original Message ----- From: "Eric Shubert" <[email protected]>
To: <[email protected]>
Sent: Friday, August 26, 2011 3:45 PM
Subject: [qmailtoaster] Re: TLS on 587
On 08/26/2011 12:08 PM, Gilbert T. Gutierrez, Jr. wrote:
Getting used to using spamdyke. I have never used it before and it
seems
to be causing problems for some of my customers. I have had to IP
whitelist a couple IPs for people who have always relayed their alarms
through my server..
The issue I still have not solved is my server requiring TLS on port
587. My old server did not (It was optional before and I cannot
find the
setting to make it optional again). require TLS on 587. I am sure as I
look through Spamdyke files I will find that option.
Gilbert
---------------------------------------------------------------------------------
Let me see if I can clarify a couple things.
Port 587 requires authentication, but TLS is not required for smtp
(although TLS is highly recommended).
Spamdyke operates on port 25, and is not connected to port 587 in any
way. Running spamdyke on port 587 would be pointless, as port 587
requires authentication, and spamdyke bypasses all filters on
authenticated connections (in case any client program were to submit
using port 25).
Whitelisting certain IPs for relaying operational emails is not
uncommon. It's better to configure the client software to send with
authentication (and TLS), although that's sometimes not practical.
With this in mind, would you like to try again? ;)
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail:
[email protected]
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
