Interesting points... I've seen examples of ISPs using port 587
(requiring AUTH, but not SSL/TLS), but not yet one that requires AUTH
and SSL/TLS on that port. I guess that's one reason why I use my ports
587 and 465 the way I do... I'll follow up with a little "standards
research" of my own, and possibly start using port 587 the same way I do
port 465 and slowly start migrating my users into using 587 (with
SSL/TLS required).
However, the point of the posting was to answer the original question
about adding port 587 (or 465) by simply starting another qmail-smtp
process (using supervise) and setting different environment variables to
REQUIRE AUTO and/or SSL/TLS.
One final point though -- I often slip into writing SSL/TLS as simply
SSL - My bad on that -- but the fact is, I'm not aware of any "secure"
protocol that requires the use of one, but not the other (presumably,
forcing the use of TLS over SSL because of encryption aging or other
security concerns). Essentially, we try the "best" encryption
technologies first, then fall back to the weaker ones -- but require ONE
of them to work to enable communications. I would assume (given the
essential "newness" of encryption technologies and IP), that we'll
eventually "sunset" some of the older encryption methods -- but I would
also hazard a guess (knowing how the Internet Community moves on these
things) that it'll be a long time before we get consensus to do so.
Dan McAllister
IT4SOHO
On 1/20/2012 4:54 PM, Eric Shubert wrote:
This is an interesting aspect of email history, and has been clouded
with confusion for quite some time. I'd like to comment on a few
things here.
On 01/20/2012 11:20 AM, Dan McAllister wrote:
Eric, et. al:
The same *qmail-smtp* program (different instances) listens on all 3
ports (if you have them configured) - the controlling "features" are:
1) the port number listed on the exec line (25, 587, & 465 are the most
common)
2) the status of the REQUIRE_AUTH environment variable (undef or 0 means
auth is allowed - it's always allowed - but, NOT required, 1 means auth
will be required)
3) the status of the SMTPS environment variable (undef or 0 means SSL is
allowed - it's always allowed - but NOT required, 1 means SSL will be
required)
Thanks for putting this succinctly. This deserves to be on the wiki if
it's not.
NOTE: To get around some ISP's blocking of port 25, some sites actually
use port 26 (an unassigned well-known-port) as an "alternate" SMTP port
- this would be implemented in the QMT exactly as these other ports are
added, except using the different port number.
That's news to me, and nice to know. I typically use another unused
port as well, but instead of creating a new qmail-smtp instance, have
a firewall redirect that ports' traffic to port 25. I think this
method is simpler and leaner.
As I mentioned in my hotwo a moment ago, the ports each have a
"standard" way they're supposed to work:
SMTP (25):
Auth = allowed (not required)
SSL = allowed (not required)
SUBMISSION (587):
Auth = Required
SSL = allowed (not required)
SMTPS (465):
Auth = Required
SSL = Required
I'm glad you put "standard" in quotes. Conventional would be a good
word there.
As to the port 465 being "depreciated"
The word is "deprecated" btw.
there is a bit of controversy
over that...
There's no doubt about that. ;)
originally, 465 was designed to be /the/ SSL port (the same
way 443 is /the /https port companion to the http port of 80) -- BUT
they modified the SMTP protocol to /allow /the use of SSL - even on port
25, so the NEED for a separate port JUST to support SSL became
depreciated...
This is the most informative post I found with google just now:
http://forums.contribs.org/index.php/topic,42378.msg199559.html#msg199559
I believe that it is correct that port 465 has never been RFC
specified (is not a standard), and the IANA has indeed revoked it
(http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml).
This is not to say however that port 465 (smtps) is not widely used
and implemented. Indeed it (still) is.
however, several ISPs have started moving towards
REQUIRING their users to use port 465 (and SSL) when sending messages
from off their networks (e.g.: from mobile devices and laptops that may
be connected on other WAN service providers). (Verizon has done this in
some areas, but I don't think all areas yet).
I'm not familiar with what Verizon's doing, but I do know that google
now requires encryption for submitting emails:
http://support.google.com/mail/bin/answer.py?hl=en&answer=78799
They support ports 465 (SSL) and 587 (TLS). I believe that port
587/TLS is preferred (or at least should be, as it *is* standard), and
port 465/SSL is there only for backward compatibility. They do not
need port 465 to enforce encryption, as their port 587 session does
not offer authentication until STARTTLS has been successfully
initiated. This is pretty neat, and something that I hope spamdyke might
The usefulness of port 465 is no longer in providing the only
SSL-enabled SMTP access anymore -- now its usefulness is in providing
SSL-ONLY SMTP access... which is exactly how Kalil (and Verizon and I
myself) tend to use it...
I'm not clear what you mean by SSL-ONLY, unless you're meaning to
support clients which can do SSL but not TLS (such as Outlook'03).
There are indeed still clients in use that can do SSL (aka SMTPS) but
not TLS.
It would be nice if spamdyke were able to enforce encrypted password
use, as dovecot does. I don't know if this is in Sam's future changes
list or not, but we should check and see if this feature can be
escalated. It would seem to be easy to implement.
I think the BL here is not what's standard or even correct, but what's
best for QMT. While I believe that port 465 usage deserves to be
discouraged, it seems to me that QMT would be more robust if it were
included in the stock package, perhaps with the services for it
disabled by default. To me this would be a good compromise.
So what do others think about this? Let's hear from you.
---------------------------------------------------------------------------------
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]
