Eric, I think adding 465 as you state would be a good addition. In addition, are there clear instructions in the wiki for adding TLS only sessions to 587? Or did I misunderstand and that capability is not yet enabled in the qmailtoaster suite?
Helmut -----Original Message----- From: Eric Shubert [mailto:[email protected]] Sent: Friday, January 20, 2012 1:55 PM To: [email protected] Subject: [qmailtoaster] Re: how to SMTPS submission/port 587 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-po rt-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: [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]
