Re: Re-reading "SERVICES" file
- From: J de Boyne Pollard <J.deBoynePollard@xxxxxxxxx>
- Date: Tue, 8 Dec 2009 03:20:38 -0800 (PST)
P> When I started MR2 it was sending smtp to port 587
P> - the one that was set when I booted. SO, it is getting
P> the port from another source.
There are lots of clueful people all saying the same thing, here.
Trevor Hemsley put it best. It looks like MR/2 ICE is broken, and
wouldn't get the GNKSOA-MUA.
<URL:http://homepage.ntlworld.com./jonathan.deboynepollard/Proposals/
gnksoa-mua.html#PreferSubmissionToRelay>
Properly written applications really do call getservbyname_r() or
getservbyname() to translate a string such as "smtp" to a port number
such as 25. And those functions really do look in %ETC%\SERVICES .
And there really is no cache of that file's contents that persists
across processes. (Others have already mentioned endservent(), which
stops a single process from holding the file open and of course has no
meaning across processes.) I write with some authority on this,
having written my own drop-in replacements for TCPIPDLL.DLL,
TCPIP32.DLL, and TCP32DLL.DLL .
But, more importantly, properly written MUAs don't look up "smtp" in
the services database in the first place, because they know that
that's the service for SMTP _Relay_, not SMTP _Submission_. The IANA
assigned name for SMTP Submission is "submission", as M. Weinkam
pointed out. And as xe also pointed out, it is a deficiency in MR/2
ICE that you are up against here. It's looking up the wrong string.
It isn't letting you manually specify the right string. And,
according to your and M. Hemsley's tests, it's secretly stashing the
answers that it gets from the lookup, somewhere else. (More on this
later.)
M. Bisset has already given you the best _local fix_ for this
behaviour: run an SMTP Submission server on port 25 on a loopback IP
address (*not* a publicly reachable one) on your own machine, and have
that server store and forward to the real SMTP Submission service that
you are wanting to use; or just have some form of pass-through SMTP
proxy on that port and IP address. You could use one of several
programs do to this. stunnel, as mentioned, is one. Bob Eager's
SMTP server and client are another. My Internet Utilities are a
third.
(You could even do it with the SENDMAIL that comes bundled with IBM OS/
2. This would involve using a second Sendmail configuration file,
though. Sendmail configuration files are notorious for being
illegible by humans, with one having as much chance of getting a
working configuration file by manual editing as one would have by
dumping the line noise from a non-error-correcting modem into a file.
And the instructions for setting up a simple submission-to-smarthost
service provided by the Sendmail company presume the existence of a
Sendmail macro language that isn't in the IBM OS/2 port, and address a
version of Sendmail that post-dates the version that IBM ported. So
this fourth option isn't a particularly appealing or convenient one.)
Another local fix would be to just run your own fully fledged MTS, and
not even bother forwarding to your ISPs' MTSes. (That comes with the
penalty of being treated by many people as a third-class Internet
citizen for running a first-class host, of course.) Again, there are
softwares available for doing that. (Again, IBM's port of Sendmail is
one, albeit far from the most convenient.) I do exactly this, myself,
using my own softwares of course.
If you want a temporary fix or a service fix, however, your only
option is to go back to the people who actually know the MR/2 ICE
code, and ask them _where the program is privately stashing its copy
of this information_. As M. Ratcliffe has already said, the only
program that has bearing here is MR/2 ICE itself. This brings us back
to the point made earlier. A lot of people have said the same thing
several times, now. You're not going to get anything new by simply
asking the same question again and again. The only possibly new point
not yet made is that it's always possible that a persistent MR/2 ICE
process is being started via your startup folder, which of course
_will_ look up the port number at startup time and remember it
thenceforth, by simple dint of continuing to run. That's a fairly
simple explanation of the observed behaviour, which I hope someone
here has already checked for. (-: The program's documentation does
state that it is written to hand off work to an already running copy
of the program.
.
- Follow-Ups:
- Re: Re-reading "SERVICES" file
- From: PaulRS
- Re: Re-reading "SERVICES" file
- References:
- Re-reading "SERVICES" file
- From: PaulRS
- Re: Re-reading "SERVICES" file
- From: baden.kudrenecky@xxxxxxxxx
- Re: Re-reading "SERVICES" file
- From: PaulRS
- Re: Re-reading "SERVICES" file
- From: Paul Ratcliffe
- Re: Re-reading "SERVICES" file
- From: PaulRS
- Re: Re-reading "SERVICES" file
- From: James J. Weinkam
- Re: Re-reading "SERVICES" file
- From: PaulRS
- Re: Re-reading "SERVICES" file
- From: Trevor Hemsley
- Re: Re-reading "SERVICES" file
- From: PaulRS
- Re: Re-reading "SERVICES" file
- From: James J. Weinkam
- Re: Re-reading "SERVICES" file
- From: PaulRS
- Re-reading "SERVICES" file
- Prev by Date: Re: Re-reading "SERVICES" file
- Next by Date: Warpstock Europe 2009 Survey
- Previous by thread: Re: Re-reading "SERVICES" file
- Next by thread: Re: Re-reading "SERVICES" file
- Index(es):
Relevant Pages
|