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.
--
-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: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
