Re: UUCP & Exim problems

Top Page
Delete this message
Reply to this message
Author: Greg A. Woods
Date:  
To: exim-users
Subject: Re: UUCP & Exim problems
[ On Tue, January 14, 1997 at 10:32:18 (-0600), John Goerzen wrote: ]
> Subject: Re: UUCP & Exim problems
>
> Hmm, AFAIK, UUCP does not care about the sender's address. When mail arrives
> at "host" (which is whatever the UUCP host is named), it is generally sent to
> the MTA (sendmail, Exim, qmail, whatever..) and treated like a normal piece of
> mail. So when my system sends UUCP mail to my ISP, the mail is just fed to
> Sendmail and I guess all the info Sendmail needs it gets from the headers. I
> think... :-)


Some versions of uux can be told who the sender was such that failures
can be bounced to the originator.

> A piece of UUCP mail has all the normal headers you'd find anywhere else --
> To, From, Subject, and a From_ line as well. So whatever MTA or MUA needs the
> info, it can get it from there. UUCP itself doesn't need the info (at least
> with mail). UUCP is just a "transport" protocol -- gets stuff from one
> computer to another. Doesn't really care about what's in it -- as long as
> both computers know what's going on, all is well :-)


Well, not exactly.

Strictly speaking UUCP mail in the traditional form of the remote
execution of "rmail" consists simply of one or more "From_" headers and
a body. Because more recent unix MUAs support features, such as
"subject" and so on, the From_ header is sometimes followed by these
additional headers.

Modern convention is that an RFC 822 compliant message including full
headers immeadiately follow the UUCP rmail "From_" header. RFC 976
gives some guidelines, though depending on what you're doing they may be
more misleading than helpful.

More modern replacements of rmail understand non-uucp addresses on the
command-line, allowing routing using Internet domain names instead of
"bang paths" of UUCP hosts. Smail-3 follows these conventions and can
be safely invoked as rmail. Note that on sendmail systems the "rmail"
is still a separate program that first compresses From_ lines, then
invokes sendmail.

RFC 976 also shows how to use other mail systems, such as UUCP rmail, to
ecapsulate BSMTP messages that can be forwarded to a full SMTP mailer on
a neighbouring gateway host.

Smail-3 additionally supports invocation as "rsmtp" (or "smail -bS")
which can be fed batched SMTP commands directly (this is slightly better
than sendmail's "-bs" (also offered by smail-3) since failures are
returned via e-mail rather than as SMTP reply codes. This eliminates
the need for the encapsulation protocol outlined by RFC 976 and thus
smail-3.2+ also includes transport definitions that use remote execution
with uux to send batch SMTP messages to a remote rsmtp. I think it
would also be possible to use the appendfile driver to place a series of
batched SMTP messages in a single file and then periodically lock this
file and deliver it to a remote rsmtp with a small wrapper program
called by cron, mgetty, or even pppd. These queue files could of course
be compressed prior to feeding them to uux too, provided the remote
program was configured to decompress them before feeding them to rsmtp.

I confess I forget if exim has emulated the -bs/rsmtp smail-3 features
or not, but I'd strongly recommend this as the way to go. Rmail should
be deprecated since it's just to limiting when the real purpose is to
correspond with remote SMTP hosts.

-- 
                            Greg A. Woods


+1 416 443-1734            VE3TCP            robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>