jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) (01/20/87)
The main problem with the munging of From: lines stems from ambiguous addresses and how each site along the way feels they should handle it as they gateway. This is not an easy problem (see Honeyman's recent paper and accompanying 1.5Mb of AI that figures it out "most of the time" :-), but most sites take it upon themselves to destroy the headers. While correct that 822 does not provide for slapping a sitename! on the front of the address, normal UUCP conventions dictate exactly that. All the ambiguity questions have been asked, but only one answer remains -- make all sites do routed addressing, so everyone can munge them appropriately, or use domain addressing. Which do you think is the more reasonable advice ...? /jordan
guy%gorodish@Sun.COM (Guy Harris) (01/21/87)
> While correct that 822 does not provide for slapping a sitename! on the > front of the address, normal UUCP conventions dictate exactly that. Nope. UUCP doesn't know beans about "From:" lines, so UUCP conventions can't dictate their format. They do require you to somehow indicate the full path that the message took to arrive at the destination, but that can be done by munging the "From_" line or by adding all the "From ... remote from..." lines to the front. Some mail user agents may not be able to cope with that, but that's a separate problem. You can fix your user agents or ignore the addresses they generate and generate reply addresses yourself. (Neither is desirable; I'd just like to be able to mail at "user@domain" and let the computer handle all the drudgework, and never have to deal with "!" in addresses ever again.)
tp@ndmce.uucp (Terry Poot) (01/22/87)
In article <16950@ucbvax.BERKELEY.EDU> jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) writes: >headers. While correct that 822 does not provide for slapping a >sitename! on the front of the address, normal UUCP conventions dictate >exactly that. Only sendmail sites slap sitename! on the front of the address in the From: line (as opposed to the uucp >From line. Sites with dumb mailers don't do this. I have seen indications, however, that sendmail sites have a tendency to put in the intermediate sites, if those sites didn't do it. I.e., it seems as though if the site I talk to runs sendmail with a 'conventional' configuration, and no other site along the path runs sendmail, the sendmail site will tack the entire path onto the From: line. Anyone know if this is correct? >All the ambiguity questions have been asked, but only one answer >remains -- make all sites do routed addressing, so everyone can munge >them appropriately, or use domain addressing. Which do you think is >the more reasonable advice ...? The question is actually: mung the From: line, or don't mung the from line. There need be no correlation with routing or addressing methods and header re-writing. There is only one alternative that seems reasonable to me: don't re-write the From: line. Reasons: 1) The only mail standard with a serious foothold in this user community (RFC822) forbids From: munging. The only way to get this stuff to work the way we all would like is standardization on SOMETHING, and this seems to be far and away the top contender. 2) The major package doing the re-writing is sendmail. Sendmail is not available to everyone, and even if it were, many people would feel little incentive to use it. Thus the re-writing alternative is not available to everyone with existing software. The alternative of not re-writing is available, in the form of smail. smail conforms to the standard given above and is available to everybody, whether they run sendmail or not. It is not necessary to give up sendmail to run smail. 3) I am told that sendmail can be made NOT to re-write the From: line simply by changing the configuration file. Non-sendmail sites can not easily be made to re-write the From: lines (given the unavailability of sendmail). Thus this is not even really an option as a net-wide standard. As far as I can see, there is only one reasonable conclusion: sendmail sites should modify their sendmail.cf to not mung the From: lines. There will then be peace and harmony throughout the net :-) >/jordan -- Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu
sob@soma.UUCP (01/27/87)
In article <1159@ndmce.uucp> tp@ndmce.UUCP (Terry Poot) writes: > >1) The only mail standard with a serious foothold in this user community >(RFC822) forbids From: munging. > > smail conforms to the standard given >above and is available to everybody, whether they run sendmail or not. It >is not necessary to give up sendmail to run smail. > It should be noted that smail does enforce conformance to RFC 822 in that it does not supply missing but necessary headers in mail that is missing them. smail is mainly an router as is uumail. sendmail (and mmdf, I think) enforce the RFC by supplying those headers if they are missing. Therefore, it is overstating the capabilities of smail to say that it conforms the RFC 822 (or RFC 920 or RFC 976).
tp@ndmce.UUCP (01/28/87)
In article <2862@soma.bcm.tmc.edu> sob@cortex.UUCP (Stan Barber) writes: >It should be noted that smail does enforce conformance to RFC 822 in that >it does not supply missing but necessary headers in mail that is missing them. >smail is mainly an router as is uumail. sendmail (and mmdf, I think) enforce >the RFC by supplying those headers if they are missing. Therefore, it is >overstating the capabilities of smail to say that it conforms the RFC 822 >(or RFC 920 or RFC 976). Good point (I assume you meant does not above). So, does anyone who does not run sendmail have either a user-agent, or something between the user-agent and router, that will do RFC822-compliant header processing? For instance, I know my mail leaves here without a message-id, and I believe this is illegal (can't find my copy of RFC822 right offhand). It would be nice to have a user agent that complemented smail's capabilities. I use mailx sometimes, and mail sometimes, because mailx thinks that any domained address needs to have .UUCP appended. My system routes messages just fine. Now I need a decent user-agent. *Sigh* As far as sendmail doing the headers, it seems that there are mixed opinions as to whether it can be made to do it right. Jordan Hayes says it can, but others (forgot who, sorry) say it can't without hacking the source. I'd heard that before, and that was what I was referring to in the message that started that argument. Several people have sent me configuration files that they claim do it right, but it will be a while before I learn enough about sendmail to be able to tell. What I'd like to get my hands on is several programs that each implement a 'layer' of what needs to be done. Sendmail already does many (or most) of these things, but the jury is still out on whether it can be made to do it completely right, which indicates to me that even if it can, it isn't easy. I'd enjoy seeing a discussion of the different facilities needed, how they should be divided among the different 'protocol layers', etc. (The ISO model might not even be a bad place to start, although I guess to match reality, we'd have to drop the layers that make sure the message actually gets where it is supposed to :-) For instance, you need : 1) A user agent (of course). Dave Taylor's ELM seems quite good, but it does its own routing (i.e. doesn't restrict itself to being a user agent, so you can't plug in things like smail or uumail (v4). One complaint I've heard about ELM is that it is so large it takes a long time to start. So there is obviously a lot of personal preference in what people would like to see in their user agent (small and quick vs large and powerful being just the most obvious). 2) Routing. Figuring out how to get it there. smail seems to cover this well. I haven't seen uumail v4, but I'm sure it does quite well at this too. 3) Transport. UUCP is less than ideal. Sendmail augments this greatly by setting up a queue and being intelligent about managing it. If it can't deliver it, it gets returned to the sender. On my system, it gets bounced back only to the previous machine, which is not good. The problem, of course is that there are pieces missing, and no standards to cover them. Also, there are functions that are hard to relegate to just one of these areas. Aliasing can meaningfully be done at least at the user agent and transport levels. Also, in the uucp world especially, there is inherent aliasing going on during routing. In the domain-based view of the world, the uucp name of a machine would have to be considered an alias. (Just think, if EVERYONE used pathalias, all we would have to put in the maps would be domain names, and only your neighbors would have to know about machine names. Duplicate machine names wouldn't be a problem. Of course we'd have to worry about the length of the rmail command line with all those 20-30 character site names!) The problem that seems to be of largest concern right now is getting the routing and transport layers to work together properly, and deciding just what each needs to do. I think that there is a lot that I don't understand in this area, as I can't see why it is as difficult as it seems to be. For example, I don't see why you can't ask the internet name server, and if it isn't on the internet, send it via uucp. This however appears to be a major problem. I also don't see why any site that is connected to the arpanet and runs pathalias can't forward any arpa mail out to uucp. If it isn't on arpanet, hand it to smail. Note, I am not saying it is this easy, if it were it would have been done. But perhaps a wider discussion of the problems might lead to a solution. Also, the problem is bigger than that, with LANs, other networks, etc. They tend not to have name servers, so how do you tell where they are. And of course nameservers in that sense are impossible in uucp, unless you are willing to wait several days for the response to the query. Most of the discussion thus far has concentrated on routing, and I think perhaps a lot of the problems thus far arise from that fact that not enough attention has been paid to transport, and it's inter-relationship with routing. Note that the only person who claims to have solved the transport problem to his satisfaction has done so by adding information to the routing data (pathalias entries) to force the transport information to be specified as an explicit part of the route. Is this the way to go? If so, what would we need to support it net-wide? Sorry to have all the questions and none of the answers, but I don't have sufficient understanding of the transport problems to propose any solutions (being a uucp only site). The alias problems are pretty easy (I just have a shell script pretending to be rmail that handles that well). -- Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu
mark@cbosgd.UUCP (02/01/87)
In article <2862@soma.bcm.tmc.edu> sob@cortex.UUCP (Stan Barber) writes: >> smail conforms to the standard given >>above and is available to everybody, whether they run sendmail or not. It >>is not necessary to give up sendmail to run smail. >> >It should be noted that smail does [not] enforce conformance to RFC 822 in that >it does not supply missing but necessary headers in mail that is missing them. >smail is mainly an router as is uumail. sendmail (and mmdf, I think) enforce >the RFC by supplying those headers if they are missing. Therefore, it is >overstating the capabilities of smail to say that it conforms the RFC 822 >(or RFC 920 or RFC 976). Stan is referring to smail version 1.0, which did not know about headers. The current version of smail, 2.3, will add the necessary headers if they aren't already there. In fact, 2.3 is so much improved over 1.0 that System V machines no longer have any reason to bring up sendmail just for the sake of domains - smail by itself handles headers, forwarding, and mailing lists just like sendmail. Since it also allows default routing to a smarter host, smail 2.3 is especially well suited to a PC class machine (running UNIX, Xenix, etc. If you want MS DOS, get UULINK.) Smail 2.3 will be posted to mod.sources Real Soon Now. Mark Horton