Arch Linux

I meant of course, adding these two lines:
smtps 465/tcp # Secure SMTP
smtps 465/udp # Secure SMTP

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.

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.

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.

(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 ...

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?

Thanks for the diff, schee, it will help people that don't want to update scripts for compatibility reasons.

/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.

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.

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.

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.

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.

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.

"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.

Here's a good services file. It's what Debian uses.

Copy, commit, close bug, done.

ping

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).

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.

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.

smtps may be deprecated but it is still required if you must support old Windows MUAs.

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.

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.

That is all fine and dandy except most providers block port 25 outbound now.

Standards and reality differ greatly in this case.

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.

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().

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.

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".