gnu@sun.uucp (John Gilmore) (08/15/85)
There's an obvious and easy way to fix this problem. Put ALL the information in the input file! The only information that needs to go over the uucp link is "run this program on this input file". No argv. The shell is happy to deal with that, and the program is free to place any interpretation on the input file. We don't need to change the already creaking uucp at this late date. It already supports what you want to do; you just aren't using it properly.
jww@sdcsvax.UUCP (Joel West) (08/16/85)
> There's an obvious and easy way to fix this problem. > > Put ALL the information in the input file! > > The only information that needs to go over the uucp link is "run this > program on this input file". No argv. The shell is happy to > deal with that, and the program is free to place any interpretation > on the input file. This won't always work. Suppose you've got a message To: ihnp4!cbosgd!bill, decvax!decwrl!june, sdcsvax!sdcc3!george, ucbvax!ucbfunky!ellen When ihnp4 gets this message, what should it conclude? That it should only try to deliver the copy to "ihnp4..."? Even if it has direct paths to sdcsvax and ucbvax? Or should it just try to deliver to everyone? Of course, if I write just To: ihnp4!bill on my home site (gould9), it will get there because of a smart pathalias mailer. This mailer does not rewrite the mail headers, only change the UUX machine routing list. Another example is blind carbon copies. A really smart mailer will distribute two copies of the message, one with the "bcc" line in the text for the "bcc" recipients; the other with "bcc" omitted for everyone else. However, most mailers seem to leave the "bcc" line out for all users, which makes it impossible to deduce in which direction the message is heading. Finally, at least some mailers do not expand a mailing list in the "To:" line but leave it as is (I think this is good). This means that the message To: mac-users@sdcsvax.UUCP can only be decoded by the explicit name expansion done at the original host site, which was carried in the delivery instructions (either via uux or SMTP.) It's actually a lot easier to write a mailer that doesn't require explicit delivery instructions, but just looks at the contents of the message. However, at this point, that approach just won't cut it. Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
campbell@maynard.UUCP (Larry Campbell) (08/20/85)
> > There's an obvious and easy way to fix this problem. > > > > Put ALL the information in the input file! > > > > The only information that needs to go over the uucp link is "run this > > program on this input file". No argv. The shell is happy to > > deal with that, and the program is free to place any interpretation > > on the input file. > > This won't always work. Suppose you've got a message > To: ihnp4!cbosgd!bill, decvax!decwrl!june, sdcsvax!sdcc3!george, > ucbvax!ucbfunky!ellen > > When ihnp4 gets this message, what should it conclude? That it should > only try to deliver the copy to "ihnp4..."? Even if it has > direct paths to sdcsvax and ucbvax? Or should it just try to deliver > to everyone?... > > Joel West CACI, Inc. - Federal (c/o UC San Diego) > {ucbvax,decvax,ihnp4}!sdcsvax!jww > jww@SDCSVAX.ARPA You're confusing the envelope with the message. Conceptually, the mail command line is the "envelope", containing delivery instructions. The message header lines are part of the message, ignored by intermediate delivery agents, and used only by the final recipient. (I'm speaking simplistically and ideally here...) To avoid shell metacharacter expansion, we just need to add an "envelope" portion of the message that contains delivery instructions. The "To:" field in the message is for the recipient's benefit only; the envelope portion would control delivery actions. Unfortunately, in today's far from perfect world, it often becomse necessary for some intermediate delivery agent to edit the message header as well, or else replies won't work. We should regard this as a temporary aberration, which can be dispensed with when a universal mail addressing scheme has been adopted. This might even happen within our lifetimes! Larry Campbell decvax!genrad The Boston Software Works, Inc. \ 120 Fulton St. seismo!harvard!wjh12!maynard!campbell Boston MA 02109 / / ihnp4 cbosgd ARPA: campbell%maynard.uucp@harvard.arpa
sob@neuro1.UUCP (Stan Barber) (08/20/85)
This seems more like a discussion for net.mail.headers.... In article <138@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: > > Conceptually, the mail >command line is the "envelope", containing delivery instructions. The >message header lines are part of the message, ignored by intermediate >delivery agents, and used only by the final recipient. (I'm speaking >simplistically and ideally here...) > >To avoid shell metacharacter expansion, we just need to add an "envelope" >portion of the message that contains delivery instructions. The "To:" >field in the message is for the recipient's benefit only; the envelope >portion would control delivery actions. > > >Larry Campbell Perhaps I am wrong, but my understanding of headers (from the RFC 822 point of view, at least), is that they form the envelope of the message and the "To:" line is for the benefit of the mailer as well as the recipient. The uux command line is generated from data contained in the header (on my systems, at least). I also think that it is a bit naive to assume that any site will just forward a message without "looking" at it. This implies that systems will look at the "To:" line before forwarding. Now, I am not advocating that all sites be RFC822-compliant, but many are and will continue to be. I am mearly pointing out that the "To:" field is not ignorable for anyone wishing to route messages through sites that are RFC-822 compatable. -- Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed Olan ARPA:sob@rice.arpa here are ONLY mine & Barber CIS:71565,623 BBS:(713)660-9262 noone else's.
henry@utzoo.UUCP (Henry Spencer) (08/21/85)
> > [...put all the info in the file, not in argv...] > > This won't always work. Suppose you've got a message > To: ihnp4!cbosgd!bill, decvax!decwrl!june, sdcsvax!sdcc3!george, > ucbvax!ucbfunky!ellen > > When ihnp4 gets this message, what should it conclude? That it should > only try to deliver the copy to "ihnp4..."? Even if it has > direct paths to sdcsvax and ucbvax? Or should it just try to deliver > to everyone? The answer is, it should be looking somewhere else than the RFC822 To: line to decide who it should deliver to. The idea will work fine, if you don't insist on force-fitting RFC822 onto it. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
lmcl@ukc.UUCP (L.M.McLoughlin) (09/02/85)
Sorry I missed the start of all this. I've been try for some time to
generate enthusiasm in the UK for an rmail alternative: jmail.
Jmail is based on the mechanism used by the main UK academic network.
The actual lump of text transfered is broken up into two parts:
1) the list of addresses to send the message to.
the addresses are comma seperated and the list is terminated by an
empty line
2) the rfc822 message.
For example:
---------------------------------------------------------------
"[3120,4044]"@edxa.ac.uk,
lee@kcl-cs.UUCP,
lmjm@doc.ic.ac.uk
Date: 02 Sep 85 9:15:29 BST
From: lmcl@ukc.ac.uk
To: the great one <lee@kcl-cs.UUCP>,
a greater one <lmjm@doc.ic.ac.uk>,
"[3120,4044]"@edxa.ac.uk,
myself <lmcl@ukc.ac.uk>
Subject: Self Praise
Boy I am wonderfull.
---------------------------------------------------------------
When a site receives this uux does (effectively) "jmail < message".
Jmail will then read the destination addresses, leap up and down on the
headers and send the message off.
For two cooperating sites to change over to using jmail instead of rmail
should not be too difficult. It means changing all programs that invoke uux
to send mail so that when sending to a site that has jmail, that is used rather
than rmail.gnu@l5.uucp (John Gilmore) (09/09/85)
In article <215@ukc.UUCP>, lmcl@ukc.UUCP (L.M.McLoughlin) writes: > Jmail is based on the mechanism used by the main UK academic network. > The actual lump of text transfered is broken up into two parts: > 1) the list of addresses to send the message to. > the addresses are comma seperated and the list is terminated by an > empty line > 2) the rfc822 message. > > For example: > --------------------------------------------------------------- > "[3120,4044]"@edxa.ac.uk, > lee@kcl-cs.UUCP, > lmjm@doc.ic.ac.uk > > Date: 02 Sep 85 9:15:29 BST etc... Can you leave out the extraneous commas? Just one address per line with no extra characters or delimiters or quotes or modes or whatever would be true and utter simplicity...
lmcl@ukc.UUCP (L.M.McLoughlin) (09/12/85)
In article <84@l5.uucp> gnu@l5.uucp (John Gilmore) writes: >In article <215@ukc.UUCP>, lmcl@ukc.UUCP (L.M.McLoughlin) writes: >> Jmail is based on the mechanism used by the main UK academic network. >> .... >> For example: >> --------------------------------------------------------------- >> "[3120,4044]"@edxa.ac.uk, >> lee@kcl-cs.UUCP, >> lmjm@doc.ic.ac.uk >> >> Date: 02 Sep 85 9:15:29 BST etc... > >Can you leave out the extraneous commas? Just one address per line >with no extra characters or delimiters or quotes or modes or whatever >would be true and utter simplicity... Indeed I would have was it not for the fact that I had access to a program (the one for the UK standard) which I used as the basis of jmail and the UK standard had commas and I was asked not to create yet another standard. However if one address per line was prefered then why not?