FS#20436 - [iana-etc] /etc/services does not know about smtps

Attached to Project: Arch Linux
Opened by SeeSchloss (Schee) - Wednesday, 11 August 2010, 10:59 GMT
Last edited by Allan McRae (Allan) - Sunday, 29 April 2012, 11:23 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

This morning after installing iana-etc, I noticed postfix would not start anymore and would tell me this in its log:
Aug 11 12:21:57 aura postfix/master[18485]: fatal: 0.0.0.0:smtps: Servname not supported for ai_socktype

The cause of this is that I have enabled smtps in postfix, and while the old /etc/services knew about smtps, the new one doesn't.

Adding this line:
smtps 465/udp # Secure SMTP

fixes the problem, but I'm not sure what the right solution is... as the point of using iana-etc was, I guess, to avoid having to manage these files ourselves.
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 29 April 2012, 11:23 GMT
Reason for closing:  Won't fix
Additional comments about closing:  See comments
Comment by SeeSchloss (Schee) - Wednesday, 11 August 2010, 12:16 GMT
I meant of course, adding these two lines:
smtps 465/tcp # Secure SMTP
smtps 465/udp # Secure SMTP
Comment by Jan de Groot (JGC) - Wednesday, 11 August 2010, 12:22 GMT
The point is that smtps is not an official service registered at IANA, which means that it's not in the default /etc/services file.

Port 465 shows up Appendix A of the 1996 non-standard standard The SSL Protocol Version 3.0 as "Simple Mail Transfer Protocol with SSL". Unfortunately, it's not registered for SMTPs, it's registered for URD - "URL Rendesvous Directory for SSM" by Cisco. The recommended approach, at least for authentication, is to use START TLS encryption on submission port 587.
Comment by Jan de Groot (JGC) - Wednesday, 11 August 2010, 12:26 GMT
Hm, on second thought, this would mean that we have to fix a lot of packages (like postfix) to not use these things anymore. If I take a look at Debian, they have two sections in the file: the top lists all IANA-registered services, on the bottom there's an additional list:

#
# Services added for the Debian GNU/Linux distribution
#
That section contains an entry for smtps. We might want to add such a section also and add services that used to be in our old /etc/services and are required for packages to work.
Comment by SeeSchloss (Schee) - Wednesday, 11 August 2010, 12:55 GMT
I think adding services at the end for compatibility would be the best solution yes.

Well I did a quick diff between the old and new /etc/services and there are LOTS of changes. Most of them (10441) are new services which is fine, but 142 services have disappeared. I haven't looked at them closely yet, I'm attaching the diff.
Comment by Benoit Izac (benizac) - Saturday, 14 August 2010, 09:16 GMT
(my mail server has been down during two days)
I've always seen smtps in /etc/services but another solution,
at least for postfix, is to replace in master.cf
smtps inet n - n - - smtpd ...
by
465 inet n - n - - smtpd ...
Comment by Mark (voidzero) - Wednesday, 18 August 2010, 06:03 GMT
Actually there are two problems. The first one is that there are *so* many changes in /etc/services that it drives administrators mad. I myself had to change a *lot* of firewall scripts and network applications. I am, for one, really not happy with the new /etc/services file. I have to change a lot of ntop settings, iptraf filters, and I could go on and on and on....

But the second problem is that /etc/protocols is missing and this is unacceptable for many applications that simply require it including firewalling. This file should be returned. Is it ok to put that in this bug or should another one be filed for /etc/protocols?
Comment by Mark (voidzero) - Wednesday, 18 August 2010, 06:04 GMT
Thanks for the diff, schee, it will help people that don't want to update scripts for compatibility reasons.
Comment by Thomas Bächler (brain0) - Wednesday, 18 August 2010, 08:57 GMT
/etc/protocols is not missing, it is right where it belongs.

And about missing services: How can an application rely on a service name being present that is not IANA-assigned? All we did was switch from some stolen /etc/services file with no history and clear indication of origin to the officially assigned service numbers by the IANA. All this shows is that applications are broken, not our services file.
Comment by SeeSchloss (Schee) - Wednesday, 18 August 2010, 09:45 GMT
Well, I just looked at a few /etc/services from different machines I have access to and, every single one has smtps:

Debian and Ubuntu in a "Services added for the Debian GNU/Linux distribution"
FreeBSD just has it
Gentoo has it as an alias name for the (IANA-assigned) "urd 465/tcp" entry
OpenBSD in a "Unofficial services" section

Remember /etc/services is a list of "WELL KNOWN PORT NUMBERS", not necessarily "OFFICIAL IANA-ASSIGNED PORT NUMBERS AND NOTHING ELSE". While using IANA's list as a base is a good idea, leaving out well-known, widely used service names *will* break things - especially when removing previously included services.

However, this means managing (at least part of) this list ourselves, and I can understand a decision to just rely on an external authority instead.
Comment by Nezmer (Nezmer) - Wednesday, 10 November 2010, 13:33 GMT
Upgraded my VPS yesterday and I just noticed this.

I'm with Schee here. Leaving well-known services/ports out does not feel right especially when they're included everywhere else.
Comment by Thomas Bächler (brain0) - Wednesday, 10 November 2010, 15:53 GMT
We should put this in the PKGBUILD properly. This means we maintain a separate "unofficial services" file that is appended to the IANA-generated files. Schee, can you provide me with the "Unofficial services" list from OpenBSD? This seems like a good start.
Comment by Hervé (herve) - Friday, 08 July 2011, 10:20 GMT
Hu? Is there a problem with Flyspray?

I was googling for that Postfix error but your comments were dated August 10th 2010. And now I have logged in, all dates are replaced by my login.

I found similar reports in the forum on April 1st 2011 and August 31th 2007.

Now I wonder why I am affected only since I installed Postfix 2.8.4-1 and the one 24 hours before that was a -2 AFAIR. And the last change to /etc/services was a couple of weeks IIRC.

Yet this (old?) bug is not closed yet so there should be a reason.
Comment by Emil Micek (pantaril) - Saturday, 16 July 2011, 08:00 GMT
I'm also affected by this bug as of today. Had to add smtps entry to my /etc/services manualy. I support the debian solution to append unofficial not-IANA assigned services at the end of the file. Leaving them out completely causes lot's of headaches to many admins and i don't see any reason for this.
Comment by Mark (voidzero) - Saturday, 16 July 2011, 11:02 GMT
"How can an application rely on a service name being present that is not IANA-assigned?" Well, this is still the Internet, isn't it? :)

I have never _relied_ on IANA for anything. Archlinux used to have a fine services file. The fact that my systems went tits up about two weeks ago as a result ofa a broken services file could get a reply in the form of "well, then don't blame /etc/services but blame your software". Which is exactly the point of the first line in this comment.

That means that webcache should not be renamed to http-alt, and then back to webcache, and then to http-alt again (port 8080) and I could care less about a service named urd instead of smtps. I know smtps is deprecated, it has been for yeears in favour of TLS, but try to tell that to $random_person.

Furthermore, Changing these files should never without a .pacnew replacement so that I can vimdiff.

Please fix and close this bug.
Comment by Mark (voidzero) - Saturday, 16 July 2011, 11:08 GMT
Here's a good services file. It's what Debian uses.

Copy, commit, close bug, done.
Comment by Mark (voidzero) - Friday, 12 August 2011, 22:08 GMT
ping
Comment by Tom Gundersen (tomegun) - Saturday, 13 August 2011, 09:31 GMT
I was asked to give my two cents:

Either someone needs to petition iana to amend the list if there is something lacking, or, if that is impossible, there needs to be some sort of cross-distro effort to provide a secondary list. If each distro should customise the list on a case-by-case basis, we will all go mad.

I vote in favor of closing this as WONTFIX (upstream).
Comment by Florian Pritz (bluewind) - Saturday, 13 August 2011, 09:32 GMT
SMTPS is useless because remote mail servers can't use it because they don't know it exists and trying 2 ports per MX is just stupid.

If you really need that, you should create an aur package that provides iana-etc and uses a different list, but IMHO we should stick to upstream.
Comment by Mark (voidzero) - Saturday, 13 August 2011, 11:05 GMT
smtps has been deprecated for many years, but is still in use by many. And it's not only about smtps. There are other common service names that are not included by iana, but have been added by e.g. debian and bsd. But debian's services file is also a bit unclean because they define both udp and tcp in the same name... that's not so nice, but it seems that this has been (used to be?) iana's policy for a long time. Examples of service names debian has added: socks/1080, openvpn/1194, kazaa/1214, radius/1812, nfs/2049, mysql/3306, distcc/3632, svn/3690, sieve/4190 (tcp-only), sip/5060, xmpp-client/5222, postgresql/5432, x11/6000, http-alt/8080 and many many others.

Do we want a strict, narrow, iana-only services file or rather have a file that will prevent future bug reports and supports more service names? My gut feeling is in favour of the latter option, but on the other hand, 'man services' refers to rfc1700 (http://www.ietf.org/rfc/rfc1700.txt), which states:

The common use of the Internet protocols by the Internet community
requires that the particular values used in these parameter fields be
assigned uniquely. It is the task of the IANA to make those unique
assignments as requested and to maintain a registry of the currently
assigned values.

After some more digging it seems that smtps was already revoked in 1998: http://www.imc.org/ietf-apps-tls/mail-archive/msg00204.html, found via http://readlist.com/lists/postfix.org/postfix-users/18/94843.html.

I can only come to one conclusion after having read these pages which is the same as tomegun's conclusion: WONTFIX sounds good, we can't keep supporting deprecated stuff ad infinitum while we are also working with and/or preferring standards. It would be nice if we can let the arch users know that we are using an iana-only services file, and maybe an iana-etc-deprecated package could be created as an alternative, though i'd prefer it if that were not only in the aur.
Comment by Dale Blount (dale) - Wednesday, 24 August 2011, 17:31 GMT
smtps may be deprecated but it is still required if you must support old Windows MUAs.
Comment by Mark (voidzero) - Thursday, 25 August 2011, 13:35 GMT
Yes, the question is not 'is it still being used' in the case of smtps. The question is, should archlinux still put that into /etc/services.
Comment by Jan de Groot (JGC) - Thursday, 25 August 2011, 13:51 GMT
It has been revoked as "standard" 13 years ago. If you want to put up a service that has been deprecated 13 years ago, you can put it in /etc/services yourself. As for supporting old Windows MUAs: they work fine with SSL if you set the port to 25. They will do TLS instead then.
Comment by Dale Blount (dale) - Thursday, 25 August 2011, 14:01 GMT
That is all fine and dandy except most providers block port 25 outbound now.

Standards and reality differ greatly in this case.
Comment by Thomas Bächler (brain0) - Thursday, 25 August 2011, 14:09 GMT
And by "most provider's" you mean what exactly? I have experienced this once, and that was in a huge public wireless network.

The fact remains: We can add /etc/{services,protocols} to backup=(), and anyone who requires non standard entries in there, can add them.
Comment by Dale Blount (dale) - Thursday, 25 August 2011, 14:30 GMT
In the US 3 of the 4 large DSL providers and at least 3 of the top 5 cable providers block 25 outbound (except to their mail servers).

I'd be fine with adding them to backup().
Comment by Jan de Groot (JGC) - Thursday, 25 August 2011, 14:32 GMT
So? That's still not a reason to setup smtps on port 465. That's why they reserved port 587 for "submission", which is usually a plain SMTP port that forces STARTTLS and SMTP AUTH.

IMHO not having /etc/services and /etc/protocols in backup is a real bug, but adding non-standard ports by default because something non-standard might want to use it is a no-go.
Comment by Allan McRae (Allan) - Sunday, 29 April 2012, 11:22 GMT
Added the backup entries for /etc/{protocols,services} in the PKGBUILD in SVN trunk. No point doing a rebuild for that...

Closing as "Won't Fix".

Loading...