HP TCPIP SMTP setup for Process PMAS, is it even possible?
Rich Jordan
of getting its Precisemail Antispam to work on the same node as the HP
TCPIP SMTP service is that it isn't possible to get that service to
cooperate. I've tried various methods of getting it to run on an
alternate port, making it only listen to requests at a specific IP
address (on a secondary ethernet interface), etc. to no avail.
Best I could do, and it would not survive a restart of the SMTP
service, or a reboot, was to have it listening on port 2525 of the
primary interface and IP address, and on port 25 _and_ port 2525 of the
second interface/IP address, and PMAS complaining that it could not get
a connection to port 25 (hopefully at the primary IP address, but I
couldn't get that config to work the same way after a reboot, so gave
up on finding out).
I don't have a second box available right now to let TCPIP SMTP be on
its own. I can't run the big powerhungry old one that my shiny new
DS10L replaced (circuit breakers pop with both online). I also won't
have time to get PMDF up (ain't the hobbyist program great? Every time
I get new toys to play with at home, work seems to sense it and gets
very intrusive on my time) so it looks like for now PMAS will have to
wait until I do have time to plow through that package.
The antispam is not that important at home right now, getting PMDF up
and running was the priority; it just seemed like PMAS would be an easy
starter.
Right now, after several attempts, plus manually deleting and restoring
the SMTP service definitions, the DS10L is happily responding to email
connections on both IP addresses, and at port 25 and port 2525 (the
alternate address I tried to configure) on each address. None of that
is reflected in the configuration or in the online service information,
nor is port 2525 showing up in the TCPIP$SERVICE.DAT file, so I'm going
to restore my pre-test backup to fix things.
Is this just an unworkable combination? Perhaps the HP images have the
port hardcoded in them, despite the appearance of means to change it in
the command utilities... along with ignoring a specified service IP
address.
Rich
Hunter Goatley
> I think the reason Process doesn't mention methods in its documentation
> of getting its Precisemail Antispam to work on the same node as the HP
> TCPIP SMTP service is that it isn't possible to get that service to
> cooperate. I've tried various methods of getting it to run on an
> alternate port, making it only listen to requests at a specific IP
> address (on a secondary ethernet interface), etc. to no avail.
>
"fairly easily change the port number for SMTP in the service
database, or add a second service listening on a different port number."
I've not actually tried this with TCP/IP Services in many years, so
I'm not exactly sure how you change it.
Of course, I feel obligated to point out that you should be
running MultiNet or TCPware instead of TCP/IP Services.... ;-)
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
PreciseMail Anti-Spam Gateway for OpenVMS, Tru64, Solaris, & Linux
goath...@goatley.com http://www.goatley.com/hunter/
JF Mezei
> Is this just an unworkable combination? Perhaps the HP images have the
> port hardcoded in them, despite the appearance of means to change it in
> the command utilities... along with ignoring a specified service IP
The TCPIP Receiver is an image which is invoked by the TCPIP Services
kernel upon reception of a call to the port defined in the service. It
isn't something that runs all the time , listening to a port. It is
invoked only on-demand.
If you define the setvice to listen to port 2025, you can test it:
TELNET host/port=2025
once connection is established, you should be getting a 200 type header
welcoming you to the VMS smtp server.
You can type "QUIT" to then exit from the receiver.
Rich Jordan
I am able to get the system listening to port 2525. THe problem
is that, even after creating a new service on port 2525 (you can't
change the port number of the existing service), deleting the service
that is listening to port 25, and in fact even after defining the new
SMTP service to listen to port 2525 on _only_ the second interface's IP
address, and restarting TCPIP or even rebooting, I still get the
receiver listening on port 25 _and_ port 2525, and on both the
secondary and primary interfaces.
The one time I seemed to get the service to only respond on port
2525 (both interfaces) and port 25 (secondary interface only) did not
survive a reboot; if I can't free up port 25 for PMAS, then I can't run
PMAS on the same system as the TCPIP Services MTA.
Hunter,
I'll check the wizard posts. Maybe there's a non-obvious solution
since the documentation is pointing me to nonworking ones. Thanks! As
to Multinet or TCPware... wish I could. I was using TCPware V1.2 (I
think the version we had was called TCP-FTP) at my first VMS site job.
While my hobby system is all for my own use, the fact is that only our
remaining VAX customers (and our in-house VAX) and one Alpha site (two
nodes) are using TCPware any more (nobody here uses Multinet). All the
other Alpha customers are running the HP product because it came with
the system. I'm running at home the combination that is closest to
what I have to work with at work, with web services, PHP/Python, Java,
etc... learn at home, test at work on our systems, and implement on
customers.
Our customers tend to be small sites (with two exceptions), but
many of them are running their single domain email on their Alphas, for
which the TCPIP Services MTA is adequate. PMAS would be a godsend...
but I really want to get it running with TCPIP services because thats
what they have. None of them are equipped with a second Alpha, and if
they want spam protection now we have to go with another product, PC
based usually due to cost (like Praetor), and at that point the
pressure immediately starts up to have the pc also do the mail, or get
exchange, yadda yadda... Getting this working means we can at least
try to interest the customers in it and keep running things on the
Alpha. Having to add MX or an alternate stack to the price (with
ongoing support costs, initial work to get webserver and other packages
'switched over') just isn't going to happen.
Rich
(who will be running PMDF at home so it won't matter from the hobbyist
perspective in the long run)
JF Mezei
> The one time I seemed to get the service to only respond on port
> 2525 (both interfaces) and port 25 (secondary interface only) did not
> survive a reboot; if I can't free up port 25 for PMAS, then I can't run
> PMAS on the same system as the TCPIP Services MTA.
HELP SET CONF ENABLE_SERVICE
You might wish to SET CONF /NOENABLE SERVICE SMTP
Then SET NOSERVICE SMTP
Then look at TCPIP$SERVICE.DAT to ensure that the SMTP record has been
removed.
TCPIP$SERVICE.DAT in SYS$COMMON:[SYSEXE] has, as primary key, the first
28 bytes of the record: This 28 byte key must be unique in the indexed file.
16 bytes -> Service name
4 bytes -> unknown (seems to always be 0000100)
2 bytes -> port number
2 bytes -> protocol 006 = TCPIP 011 = UDP
4 bytes -> address to listen on.
For BIND, you'll have two records, one for TCP and another for UDP.
Note that the SERVICE.DAT database seemes to contain node-independant
information. So it appears it would be impossible in a cluster to have
one node have "SMTP" listen to port 2025 on all addresses/interfaces on
that node, and another node listen to port 25 on all
addresses/interfaces on that node because enabling "SMTP" would enable
all services defined with name "SMTP". But by naming the service
differently, you would be able to do that.
But that isn't all. TCPIP$CONFIGURATION.DAT contains the list of
services that are enabled on that node. (I think that is what it is).
But it seems to contain only the service name. So I think that if you
enable BIND, it will enable all services named "BIND" (including the TCP
and UDP versions in the above example).
I think that the main SMTP engine (the symbiont) is defined solely in
the TCPIP$CONFIGURATION.DAT file (hence defined solely with SET CONF SMTP)
What you might also try is to have the SMTP receiver defined as "ZSMTP"
listening in port 25. Perhaps it will be started after the PMAS service
and thus won't be able to get port 25 if it insists on listening to it.
So you can use DUMP/REC on the TCPIP$SERVICE.DAT file to ensure that you
no longer have a service defined to listen to port 25. Then, define the
new PMAS service to listen on port 25.
This should generate two different and distinct services that are not
related in any way and can be enabled separately. Both could then listen
to any interface.
And based on what I have seen, it should theoretically be possible to have:
node1: addresses 10.0.0.1 and 10.0.0.2
SMTP: /file=pmas_software/port=25/address=10.0.0.1
SMTP: /file=tcpip$receiver/port=25/address=10.0.0.2
This should create 2 records in the TCPIP$SERVICE file. And you then
enable service SMTP which would enable both.
The kernel would then only trigger tcpip$receiver when calls come in on
address 10.0.0.2
this is all "should".... Haven't tested it.
Note: /address=0.0.0.0 means that the service is enabled automatically
on all interfaces on that node, even interfaces that appear after the
service was started.
And when using /ADDRESS, only one address can be included per record.
HOWEVER, I do not think that you can modify an existing record where
there are multiple services of the same name, you need to delete it and
recreate it from scratch.
Rich Jordan
> 28 bytes of the record: This 28 byte key must be unique in the indexed file.
>
> 16 bytes -> Service name
> 4 bytes -> unknown (seems to always be 0000100)
> 2 bytes -> port number
> 2 bytes -> protocol 006 = TCPIP 011 = UDP
> 4 bytes -> address to listen on.
I tried using PATCH to just change the port number over the weekend.
The service definition showed port 2525 when running but I still got
SMTP response on port 25 on both interfaces.
I also tried completely deleting the service as you mentioned and
rebuilding it from scratch, re-enabling, etc. In that case I did
finally get it responding on port 2525, but still on both interfaces
even though the service was set up to with only the secondary address.
However without the SMTP startup running, required logicals are not
present.
If you run the SMTP startup after performing this work, the logicals do
get defined, but the queue won't run; I haven't found the error yet.
When I try to connect to port 2525, it connects and immediately
disconnects. The TCPIP$SMTP_RECV_RUN.LOG file (once verification is
turned on) shows:
$ run SYS$SYSTEM:TCPIP$SMTP_RECEIVER.EXE
SMTP_RECV_INIT: smtp$get_config failed: status: %RMS-E-RNF, record not
found
SMTP_RECV_MAIL: init failure: status: %RMS-E-RNF, record not found
%RMS-E-RNF, record not found
I assume its looking for the SMTP record in TCPIP$CONFIGURATION.DAT
file, which of course is gone. There is a record for the new service
(SMTP2525).
I have a feeling there may be too much hardcoding going on in there to
get this to work, but I'll keep pounding on it as I have time. If so
thats a real shame.
JF Mezei
> I tried using PATCH to just change the port number over the weekend.
> The service definition showed port 2525 when running but I still got
> SMTP response on port 25 on both interfaces.
patching it wouldn't have told the kernel to disable the old service and
enable the new definition.
> I also tried completely deleting the service as you mentioned and
> rebuilding it from scratch, re-enabling, etc. In that case I did
> finally get it responding on port 2525, but still on both interfaces
you need to look at the output of netstat. *.25 indicates it is
listening on any interface. If you get another line for .25 with a
specific address it would indicate that the kernel has got 2 definitions.
> However without the SMTP startup running, required logicals are not
> present.
Correct. TCPIP$RECEIVER.EXE reads in the full configuration data for the
mail service for every email that is received. So it needs access to the
logicals that point to the directory etc in order to load those config
files. Those logicals are set by the symbiont side of the SMTP software.
>> I assume its looking for the SMTP record in TCPIP$CONFIGURATION.DAT
> file, which of course is gone. There is a record for the new service
> (SMTP2525).
You really need the SMTP record in the configuration.dat file. This is
the "real" cofig for the mail *service*. The TCPIP> SET SERVICE SMTP
only defines the receiver portion.
You might want to SHOW CONF SMTP/full and rebuild that record with the
SET CONF SMTP , or run @TCPIP$CONFIF to recreate the SMTP service from scratch.
> I have a feeling there may be too much hardcoding going on in there to
> get this to work, but I'll keep pounding on it as I have time.
the tcpip$smtp_receiver.exe seems to just rely on the auxiliary server
(giving it a devuice to talk to) instead of listening to any port.
I think you should start from scratch and go at it step by step. I think
your initial testing may have screwed up your final tests.
Rich Jordan
>> The service definition showed port 2525 when running but I still got
>> SMTP response on port 25 on both interfaces.
>
> patching it wouldn't have told the kernel to disable the old service and
> enable the new definition.
>
A backup of all the TCPIP*.DAT files was made. TCPIP was shut down, the
SERVICE file was patched for port 2525, then the system was rebooted.
When running again, SHOW SERVICE SMTP/FULL showed port 2525. SHOW
CONFIG SMTP does not display the port information (nor can you set the
port through the CONFIG SMTP method).
This was just a test anyway...
>> I also tried completely deleting the service as you mentioned and
>> rebuilding it from scratch, re-enabling, etc. In that case I did
>> finally get it responding on port 2525, but still on both interfaces
> you need to look at the output of netstat. *.25 indicates it is
> listening on any interface. If you get another line for .25 with a
> specific address it would indicate that the kernel has got 2 definitions.
As soon as I figure out what options are needed to do anything useful;
its rather
obtuse. However the SHOW SERVICE clearly showed nothing on port 25,
and the
new service on port 2525.
>> However without the SMTP startup running, required logicals are not
>> present.
>
> Correct. TCPIP$RECEIVER.EXE reads in the full configuration data for the
> mail service for every email that is received. So it needs access to the
> logicals that point to the directory etc in order to load those config
> files. Those logicals are set by the symbiont side of the SMTP software.
>
But running the SMTP startup errors out if the service is not in the
tcpip$service file, even if its still in the configuration file.
>> I assume its looking for the SMTP record in TCPIP$CONFIGURATION.DAT
>> file, which of course is gone. There is a record for the new service
>> (SMTP2525).
>
> You really need the SMTP record in the configuration.dat file. This is
> the "real" cofig for the mail *service*. The TCPIP> SET SERVICE SMTP
> only defines the receiver portion.
Good to know, thanks.
>
> You might want to SHOW CONF SMTP/full and rebuild that record with the
> SET CONF SMTP , or run @TCPIP$CONFIF to recreate the SMTP service from
> scratch.
>
There are some options that don't appear to be settable from the CLI,
f.ex the log file name, though I may not have looked hard enough to be
absolutely certain.
>> I have a feeling there may be too much hardcoding going on in there to
>> get this to work, but I'll keep pounding on it as I have time.
>
> the tcpip$smtp_receiver.exe seems to just rely on the auxiliary server
>(giving it a devuice to talk to) instead of listening to any port.
>
> I think you should start from scratch and go at it step by step. I think
> your initial testing may have screwed up your final tests.
Emminently sensible, even though I have all the saved dat files. The
config is not (yet) so complex that it will be difficult to do. Maybe
look at modifying the TCPIP$CONFIG file to do the port changes right up
front, if possible.
Rich
JF Mezei
> When running again, SHOW SERVICE SMTP/FULL showed port 2525. SHOW
> CONFIG SMTP does not display the port information (nor can you set the
> port through the CONFIG SMTP method).
SHOW SERVICE SMTP displays information about the receiver.
SHOW CONF SMTP shows information about the symbiont.
And a call comes into port XX, the TCPIP kernel creates a process under
the username defined in SET SERVICE and invokes the command procedure
defined in SET SERVICE and there is a logical name available that points
to the network link that the application (in this case
TCPIP$SMTP_RECV.EXE) assigns a channel to to communicate with the remote client.
The information in SET SERVICE is used to create the process. Once the
process is created, the TCPIP$SMTP_RECV.EXE doesn't care about the info
in SET SERVICE. But it does actively consult the information in SET CONF
SMTP for information about the core mailing system.
If you enable tracing/logging for the receiver, it becomes very evident
since it displays the full config of the symbiont upon startup.
The receiver doesn't seem designed to listen to a port for incoming
calls. It appears to have offloaded this to the TCPIP kernel (auxiliary server).
Remember that if you SET SERVICE SMTP/PORT=2525/ADDRESS=1.2.3.4, it
will create a new record, and the old record with SMTP at port 25 and
address 0.0.0.0 still exists.
It is also likely that the port number is stored in more than one place,
so patching only the port number in the key may not be enough.
i.e. It isn't enough to ensure you patch one record. You need to ensure
that you remove the old record.
> > you need to look at the output of netstat. *.25 indicates it is
>
> As soon as I figure out what options are needed to do anything useful;
$ @sys$manager:tcpip$define_commands
$ netstat
this gives you a list of all ports that the stack is listening to. And
it also gives you a list of all current established connections (inbound
and outbound).
> obtuse. However the SHOW SERVICE clearly showed nothing on port 25,
> and the new service on port 2525.
It could be. Telnet has some hardcoded port number that cannot be changed.
One way to try is to do the following:
define a service on port 2525 that calls the tcpip$smtp_receiver stuff,
but call it "CHOCOLATE".
define a service in port 25 that calls your spam software and call it "SMTP".
This way, the TCPIP stack may be happy with the fact that there is an
"SMTP" service defined on port 25 and not realise that it invokes
software that isn't the normal one.
> There are some options that don't appear to be settable from the CLI,
> f.ex the log file name, though I may not have looked hard enough to be
> absolutely certain.
SET SERVICE name /LOG_OPTIONS=FILE=disk:[dir.dir]file.type
It isn't documented in the on-line help. You need to disable and enable
the service for it to show up.
Also, you may look at HELP ENABLE SERVICE. You can enable a service
selectively by port and/or address. Haven't tried it though.
Rich Jordan
thanks for taking the time. I'll work with it tonight; since my
only daytime connection to the box is via telnet I can't do the
reconfig from here.
> Remember that if you SET SERVICE SMTP/PORT=2525/ADDRESS=1.2.3.4, it
> will create a new record, and the old record with SMTP at port 25 and
> address 0.0.0.0 still exists.
I did a set noservice smtp and it prompted through both smtp
entries; I removed the port 25 one, left the port 2525 one, double
checked it, and rebooted. Same issues; even though no service was
listed for port 25 I still got responses on it
> $ @sys$manager:tcpip$define_commands
> $ netstat
I was running netstat from the TCPIP prompt; there it was prompting for
_Options:
> SET SERVICE name /LOG_OPTIONS=FILE=disk:[dir.dir]file.type
>
> It isn't documented in the on-line help. You need to disable and enable
> the service for it to show up.
That is a logical command setting for it, but I was relying on online
help; my printed docs are at work.
I'm rebuilding the config tonight and will try some of the other
options you've pointed out. Thanks again.
Rich
Rich Jordan
TCPIP data files, and everything that looked to be modified, I've got
my system into a state where HPSWS will no longer run. The httpd
command returns no errors, the SWS logfile is empty, it just won't
start. Even rerunning the configuration, or removing and re-installing
CSWS had no effect, so it looks like a system disk restore will be
needed (I kept backups at stages of testing).
Nothing I did touched the Apache directories, but if Apache loaded info
into the TCPIP$*.DAT files then the purges would have removed it.
Unfortunately the reconfig and reinstall apparently didn't restore
whatever broke.
I may try again, but as of now I'd have to guess its not possible to
run PMAS and TCPIP SMTP on the same system because its not possible to
get SMTP to run on a different port without causing truly unpleasant
side effects.
Thats a real shame...
Rich
Rich Jordan
Somehow protection on TCPIP$HOSTS.DAT got munged, lost world access.
Apache/SWS quietly declines to start under those conditions. Found it
in the audit logs, but the failure was not set for alarms so I didn't
see it earlier.
So the system is back up and happy without a restore. I still don't
have TCPIP SMTP working on an alternate port, but at least I know all
the experimentation really didn't kill Apache.
More experimenting to follow. If anyone out there has gotten this to
work I'd really like to hear about it. Thanks!
Rich