Mail Rewrite Rules Problem - V2.0
Bob Longo
can help me figure out what is going on - or if this is a problem in UUCP V2.
Our configuration is as follows; UUCP V2 is installed on a MicroVAX. Most
users at our company don't have a username on this MicroVAX. We have
subscribed with PSI for our connection to UUCP. PSI took care of registering
our domain as "sfpp.com". They are the only site we dial for UUCP mail. Our
hostname was chosen to be "sfpp". The PSI host we dial is "uupsi5".
We desire to have the following mail rewrite rules:
1) mail addressed to "us...@sfpp.com" will be forwarded to our main mail
system - SPVX01::.
2) mail addressed to "us...@node.sfpp.com" will be sent to the DECnet
node specified in the second level domain.
3) mail sent out from a node in the network will appear that it was
sent from "us...@node.sfpp.com".
The problem is that mail addressed as "us...@sfpp.com" is not being forwarded
to the mail system SPVX01::. The files stay in in the spool directory until
they expire. The X file in UUCP_SPOOL (or in UUCP_SPOOL:[.UUPSI5]) contain the
lines:
U uucp sfpp
F D.sfpp03L
I D.sfpp03L
C rmail graue
(where "graue" is the username the mail was addressed to, who like most other
users does not have a username on this system).
A test D.SFPP03_L file as found in the spool directory contains:
From sfpp.com!longo Sun, 13 Dec 92 21:20:27 PST remote from sfpp
Received: by sfpp.com (DECUS UUCP /2.0/2.0/2.0/);
Sun, 13 Dec 92 21:20:27 PST
Date: Sun, 13 Dec 92 21:20:27 PST
Message-Id: <009650B4DF6E...@sfpp.com>
From: "Bob Longo" <lo...@sfpp.com>
Subject: test
To: te...@sfpp.com
X-VMS-Mail-To: UUCP%"te...@sfpp.com"
X-VMS-Mail-CC: LONGO
test
The guts of my MAIL_REWRITE.RULES file (with the comments stripped out) is:
[INBOUND-TO]
*@sfpp.com spvx01::\001
*%sfpp.com spvx01::\001
sfpp.com!* spvx01::\001
sfpp!* spvx01::\001
*@*.sfpp.com \002::\001
*%*.sfpp.com \002::\001
*.sfpp.com!* \001::\002
[OUTBOUND-FROM]
*::* \002@\001.sfpp.com
* \0...@sfpp.com
[INBOUND-FROM]
*%*.bitnet@* \001@\002.bitnet
*%*@relay.cs.net \001@\002
hp-sdd!*!* \002@\001
apple!*!* \002@\001
uunet!*!* \002@\001
[OUTBOUND-TO]
*@*.bitnet \001%\002.B...@CUNYVM.CUNY.EDU
The PATHS. file contains:
sfpp %s 0
smart-host uupsi5!%s 120
uupsi5 uupsi5!%s 120
The CONTROL. file, again with comments stripped out, contains:
hostname sfpp
debug 0201
sleeptime 15
port ACU hayes uucp_port 9600 l
spool UUCP_DISK:[UUCP.SPOOL]
logfile UUCP_LOG:UUCP.LOG
logdir UUCP_DISK:[UUCP.LOG]
cfgdir UUCP_DISK:[UUCP.CFG]
debugfile uucico_dbg
sysfile UUCP_CFG:SYSTEMS
UUCP_ALLOW_UUCPCMD Y
UUCP_BATCH_NODE "-"
UUCP_BATCH_UUCICO_CALLOUT_JOBS 1
UUCP_DATA UUCP_DISK:[UUCP.DATA]
UUCP_DOMAIN_NAME "sfpp.com"
UUCP_DUMP UUCP_DISK:[UUCP.DUMP]
UUCP_PATH_DATA UUCP_DISK:[UUCP.DATA.MAPSRC]
UUCP_POSTMASTER LONGO
UUCP_RCVDNEWS UUCP_DISK:[UUCP.RCVDNEWS]
UUCP_TIME_ZONE PST
UUCP_TOOLS UUCP_DISK:[UUCP.TOOLS]
It is interesting to note that if the mail is addressed as "user%sfpp.com",
the "C rmail" line in the spool directory contains the entire
"C rmail user%sfpp.com", while mail addressed to "us...@sfpp.com" contains only
"C rmail user". So something is stripping off the "@sfpp.com" part of the
address, I suspect prior to it getting to the rewrite rules.
It does not appear that there is anything wrong in the mail header causing
this, because it even happens when I send mail from my own system (meaning it
never leaves to go to the neighboring host).
Does anyone know what could be causing this behavior and how to correct it?
Thanks,
-Bob Longo
Dean Nedelman
> F D.sfpp03L
> I D.sfpp03L
> C rmail graue
rewrite rules. Note that is says graue, NOT gr...@sfpp.com. This is why
it is not matching the rewrite rules.
> [INBOUND-TO]
> *@sfpp.com spvx01::\001
> *%sfpp.com spvx01::\001
> sfpp.com!* spvx01::\001
> sfpp!* spvx01::\001
> *@*.sfpp.com \002::\001
> *%*.sfpp.com \002::\001
> *.sfpp.com!* \001::\002
Add the following line to the end of the INBOUND-TO section
* spvx01::\001
>-Bob Longo
--
Dean (The Shadow)
+---------------------------------------------------------------------------+
| Dean I. Nedelman nede...@pasadena-dc.bofa.com |
| Advisory Systems Engineer nede...@spacm1.spac.spc.com |
| Bank America System Engineering nedelman%spacm...@elroy.jpl.nasa.gov |
| Pasadena, CA 91101 {...,decwrl,ames,usc}!elroy!spacm1!nedelman |
+------------------------------------+--------------------------------------+
| Systems programmers are the high | *** PGP Public Key *** |
| priests of a low cult. | Available upon request |
+------------------------------------+--------------------------------------+
Tom Allebrandi
>> U uucp sfpp
>> F D.sfpp03L
>> I D.sfpp03L
>> C rmail graue
> ^^^^^^ This is the text string that is passed to the mail
> rewrite rules. Note that is says graue, NOT gr...@sfpp.com. This is why
> it is not matching the rewrite rules.
>
An additional point of clarification - The X file was created by the
host that sent it to you. In your case, PSI has recognized that in
many parts of the world "gr...@sfpp.com" would be user "graue" on
your gateway machine. They never sent you the "sfpp.com" part of
the address for that reason. You night be able to ask them to.
> Add the following line to the end of the INBOUND-TO section
>
> * spvx01::\001
That's probably the easiest solution. Make sure that that line is the
last [INBOUND-TO] rule in the file. (Since it matches all patterns
it would strand any [INBOUND-TO] rules that follow it.)
Another approach which is somewhat labor intensive is to set forwarding
entires for the affected users. From a privileged account go into VMS
Mail and do
set forward/user=graue spvx01::graue
You can do this regardless of whether or not graue has an account on the
local machine. You would have to do this for every user that needs
their mail forwarded from the gateway machine. It might be easier to
forward everything via the rewrite rules and send the exceptions back via
VMS Mail forward entries :-)
Tip of the day: VMS Mail forwarding entries can be 31 characters long.
For example, I could do
set forward/user=ThomasMAllebrandi Allebrandi
to give a "full name" alias for myself.
--- Tom
Tom Allebrandi | Mail guru - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt - CMU/Tek-IP
East Chicago, IN | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306 | Internet: alleb...@inland.com
DECUServe: allebrandi | UUCP: ...!uunet!inland!allebrandi