🚀 go-pugleaf

> This "problem" exists for ALL implementations of UUCP.  At least,
> for all the ones I've seen (since V7), ....

This does not appear to be the case.  My experience with 4.3 BSD UUCP has
shown this not to be true, and my tests with 4.2 have shown there not to
be a problem as well.  It seems to be limited to HDB (and possibly to the
old System V version) of UUCP.

> There is an obvious workaround -- don't put forward addresses on
> the command line.  If you look through the comp.sources.{misc,unix}
> archive you'll find a program I did long-long ago in a job far-far away
> which implements a variety of this workaround.

This is fine as long as you are guaranteed of always routing your messages
between machines that have these kind of bilateral agreements established.
For the type of routing that is done these days, I do not believe that this
is a reliable general solution.  Any sites not having this type of bilateral
agreement will still exchange mail using "uux rmail ...", many times resulting
in the UUXQT failures.

> >From a security standpoint it makes NO SENSE for AT&T to "fix" this
> because it simply ain't broke.  It's up to us software wizards
> to do UUCP mail right.

I disagree with this.  Although it is important to check for permissions
when doing file type activity, the HDB UUXQT is actually checking the argument
list to rmail.  Please note that the assumption that I am making is that we
should be able to transfer 822 compatible messages across a UUCP link.  If
this is the case, the receiving UUCP site should handle legal 822.  For the
type of security you are refering to, if required for mail, this capability
should be built into rmail (it is the one that has to determine if the address
is a file or an encoded O/R name).

Regards,

Tim Kehres