paul@frcs.UUCP (Paul Nash) (12/03/90)
We have a dispute between the administrators of a few local machines. One of the machines runs `sendmail' (for bizzare reasons), and has a `sendmail.cf' file that re-writes the `To:' and `From:' fields in all forwarded mail. The effect on the headers is roughly as follows (`gatebox' is the [ficticious] `sendmail' pervert): incoming outgoing To: user@toaster To: toaster!user@gatebox From: me@tinytoy From: tinytoy!me@gatebox The administrator of this particular machine feels that this is perfectly reasonable, and even desirable, so that mail gets routed the way that they think fit. However, others of us think that this is not terribly sociable, and want our addresses left alone. I have tried digging through RFC822, but it has cast no light on the subject. My gut feel, though, is that each mailer should only rewrite the `Path:' field (and add a fifteen-line `Received:' field). The rest should surely be left alone (after all, _I_ know who I am). Are there any Mail Gurus out there who can elighten us? ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Flagship Wide Area Networks (Pty) Ltd paul@frcs.UUCP ...!uunet!ddsw1!proxima!frcs!paul
barmar@think.com (Barry Margolin) (12/05/90)
In article <208@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >The effect on the headers is roughly as follows (`gatebox' is the >[ficticious] `sendmail' pervert): > > incoming outgoing > > To: user@toaster To: toaster!user@gatebox > From: me@tinytoy From: tinytoy!me@gatebox > >The administrator of this particular machine feels that this is >perfectly reasonable, and even desirable, so that mail gets routed >the way that they think fit. However, others of us think that this >is not terribly sociable, and want our addresses left alone. > >I have tried digging through RFC822, but it has cast no light on >the subject. My gut feel, though, is that each mailer should only >rewrite the `Path:' field (and add a fifteen-line `Received:' field). >The rest should surely be left alone (after all, _I_ know who I am). >Are there any Mail Gurus out there who can elighten us? The rule is that when a gateway forwards mail into the Internet, the "@<host>" portion of the addresses in the header must all be recognizable to Internet hosts. Prior to the domain system, this meant that the <host> had to be in the Internet host table. Now it means that the <host> must have either an A or MX record in the domain database. So, if "toaster" and "tinytoy" are in the domain database there should be little need to rewrite them. That's the ideal. However, the fact is that many systems are still running old mailers that don't know how to use MX routing. So, if they want most hosts to be able to reply to the mail, it's safer to put an actual Internet host in the "@<host>" portion of the addresses. You may know that tinytoy recognizes the host name toaster and knows how to route mail to it. But this may not be true for all users on your side of gatebox. And do you really know what protocols are supported by all hosts you will ever send mail to? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
time@tbomb.ice.com (Tim Endres) (12/05/90)
In article <208@frcs.UUCP>, paul@frcs.UUCP (Paul Nash) writes: > The administrator of this particular machine feels that this is > perfectly reasonable, and even desirable, so that mail gets routed > the way that they think fit. However, others of us think that this > is not terribly sociable, and want our addresses left alone. > Disclaimer: I am no email guru, just been into it a long time. This is one of the longer standing debates in mail history. The original philosophy in electronic mail design was that a mailer look at the "envelope address" to work with a piece of mail and *never* touch the "envelope contents". This was fine with a single mailer and a single transport, but alas, along came other mailers and transports. With the divergence of mail mechanisms came the realization that the "envelope address" was sometimes inadequate. To solve this, some mailers began to look at the internals of the "envelope contents" to view the header information and better perform their task. While this was viewed as "wrong", it solved the problem at hand and created few of its own. Then, along came sendmail! The dark force of the mail universe! :^) For some reason, which I have never had fully explained, sendmail found it not only necessary to view headers to determine the means of transporting the letter, but to modify these headers in order to assist in the routing and reply routing of the letter through other sendmails. Mailer purists will tell you that sendmail is evil and breaks the most fundamental of rules. This is my attitude. However, sendmail administrators often have good and valid reasons for doing what they do. Clearly, sendmail performs its duties at many locations without complaints. I guess the bottom line is this: I have *never* met a sendmail installation that did not create problems by munging headers. This is a headache for the administrator as much as the mail user. Now granted, it may be only one problem out of thousands of letters, but sooner or later it happens. As an aside, my mail server recently tossed sendmail away for smail3. This was because 30% of the mail I sent bounced going out, and 40% of the replies never made it back. I am sure that had the sendmail been configured a little more the problem could have been fixed. BUT smail3 fixed the problem right away. It left the headers alone! tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uunet!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
rickert@mp.cs.niu.edu (Neil Rickert) (12/05/90)
In article <208@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: > >We have a dispute between the administrators of a few local machines. >One of the machines runs `sendmail' (for bizzare reasons), and has >a `sendmail.cf' file that re-writes the `To:' and `From:' fields in >all forwarded mail. > >The effect on the headers is roughly as follows (`gatebox' is the >[ficticious] `sendmail' pervert): > > incoming outgoing > > To: user@toaster To: toaster!user@gatebox > From: me@tinytoy From: tinytoy!me@gatebox > In an ideal world, the To: and 'From:' headers would not be rewritten. But in this ideal world only valid addresses would be used, so that rewriting is not required. If your world creates addresses such as 'user@toaster' or 'me@tinytoy', then your world is far from ideal, and the rewriting by sendmail is only rescuing you from a worse fate. A well designed 'sendmail.cf' will try to make sure that all addresses are valid. If they are not valid, it will try to add routing to make sure there is a valid internet address on the outgoing mail. If the incoming address is already valid it is normally rewritten to its incoming form. If you send me mail with a 'From:' address of 'me@tinytoy', and I find that my attempt to reply results in bounced mail and considerable annoyance, you and your postmaster are both going to get a strong message from me complaining about your broken mailers. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
bruce@balilly.UUCP (Bruce Lilly) (12/06/90)
In article <208@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: > >[ ... ] > >The effect on the headers is roughly as follows (`gatebox' is the >[ficticious] `sendmail' pervert): > > incoming outgoing > > To: user@toaster To: toaster!user@gatebox > From: me@tinytoy From: tinytoy!me@gatebox > >[ ... ] > >I have tried digging through RFC822, but it has cast no light on >the subject. My gut feel, though, is that each mailer should only >rewrite the `Path:' field (and add a fifteen-line `Received:' field). >The rest should surely be left alone (after all, _I_ know who I am). >Are there any Mail Gurus out there who can elighten us? The applicable RFC's (including 822) require that addresses on the internet must be in domain form (not ! paths), and that fully-qualified domains be used. So, if the ficticous ``gatebox'' is really something like ``foo.bar.com'', then what is being done is correct if the mail is likely to enter the Internet from that system. (systems acting as gateways between the Internet and non-Internet systems, such as the uucp network, are required to translate those ``foreign'' address syntaxes into RFC-compliant forms when gatewaying onto the Internet) If it's ``foo.bar.com'' but the mail isn't being gatewayed onto the Internet, the changes are unnecessary but harmless. Finally if ``gatebox'' is some form other than the domain naming system, such as a uucp host name, then the change accomplishes nothing. (user@toaster is not a valid RFC822 address because ``toaster'' is not a fully-qualified domain name; presumably it is a uucp host name) -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
karl_kleinpaste@cis.ohio-state.edu (12/07/90)
bruce@balilly.uucp writes: > To: user@toaster To: toaster!user@gatebox > From: me@tinytoy From: tinytoy!me@gatebox The applicable RFC's (including 822) require that addresses on the internet must be in domain form (not ! paths), and that fully-qualified domains be used. To clarify that just a bit, the RFCs require that addresses on the Internet be FQDNs _if_ they are going outside their domain of origin. Abbreviations within a domain are fine. RFC822 section 6.2.2 page 29: Since any number of levels is possible within the domain hierarchy, specification of a fully qualified address can become inconvenient. This standard permits abbreviated domain specification... When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. In the case of abbreviated addresses, the relaying service must make the necessary expansions... The "gatebox" in question is doing exactly the right thing if it is making addresses palatable to things outside your domain. If it's doing it for destinations within your domain, it's harmless but not especially useful. If your site inflicts "user@tinytoy" on my sendmail, I'm going to finish the job of address-breaking that your site started: It's going to be rewritten as user@cis.ohio-state.edu. This rewrite does the Right Thing in the usual case where Joe Random writes mail to, e.g., jane@apple. I have to interpret OneWordHostNames within the context of cis.ohio-state.edu, a host apple.cis.ohio-state.edu exists, and we hide hostnames anyway, so I rewrite all OWHNs as cis.ohio-state.edu. Since a recipient here of address "user@tinytoy" couldn't have replied directly to it anyway, I figure it serves 'em right if they have to hunt through Received: headers for the real information they needed. I post an explanatory "mail/news/finger glitches and solutions" to a local newsgroup periodically so that the users know what's what. --karl
rickert@mp.cs.niu.edu (Neil Rickert) (12/07/90)
In article <KARL.90Dec6171155@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >If your site inflicts "user@tinytoy" on my sendmail, I'm going to >finish the job of address-breaking that your site started: It's going >to be rewritten as user@cis.ohio-state.edu. This rewrite does the But if your site inflicts 'user@tinytoy' on my sendmail, its gonna be changed to 'user%tinytoy@your.relay.host', where 'your.relay.host' means the host which actually connected to me - if not known to DNS this might become 'user%tinytoy@[1.2.3.4]' (with the appropriate actual internet address. I got tired of these unqualified addresses cropping up everywhere, and the bounced mail they generate. So I added this feature to the IDA package. Look for an announcement soon of 'IDA-1.4.1' configuration kit. This won't solve all the problems of vendor supplied software which doesn't properly qualify domains, but it should help. (Sorry, it can't be done in non-IDA versions of sendmail). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
huitema@jerry.inria.fr (Christian Huitema) (12/07/90)
In article <1990Dec7.003726.28242@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: > In article <KARL.90Dec6171155@giza.cis.ohio-state.edu> > karl_kleinpaste@cis.ohio-state.edu writes: > >If your site inflicts "user@tinytoy" on my sendmail, I'm going to > >finish the job of address-breaking that your site started: It's going > >to be rewritten as user@cis.ohio-state.edu. This rewrite does the > > But if your site inflicts 'user@tinytoy' on my sendmail, its gonna > be changed to 'user%tinytoy@your.relay.host', where 'your.relay.host' > means the host which actually connected to me - if not known to DNS > this might become 'user%tinytoy@[1.2.3.4]' (with the appropriate actual > internet address. > There are two cases to consider: submission and relay. Submission is performed when a local user edit a piece of text, using some more or less adequate tools ranging from "ed" to "xmh", and "pipe" it into the "mailer". Relay is performed when a host on the network receive a piece of mail from another host, and ask the local host to relay or deliver it. In the case of relay within a single network, or more precisely within a single naming system, there is no reason to muck with anything but the envelope. In fact, any attempt to "correct" or "rewrite" the addresses in lines like "from" or "to" or "reply-to" is just bound to add noise and augment the occurence rate of irrepliable address: if the information was not correct from the beginning, it will probably stay incorrect after a rewrite. And if it was correct, it may well become incorrect. In short, the philosophy relies on the difference between names and addresses: names should be absolute, and should be the only thing present in headers, whilst using overwriting the names with addressing information using either the "!" or the "%" or the <@,@,@:> convention might be a fair game in the envelopes. On the other hand, a local mailer should make sure that the pieces of texts submitted by the suers are actually valid pieces of mail. This may involve checking the names in some headers to ensure that they are valid FQDN, and checking that the mandatory or semi mandatory fields "Date", "From" and "message-id" are present. One of the problems with sendmail is that one cannot specify in the ".cf" file which actions are to be performed on a "real" and which on a "submission". Christian Huitema
les@chinet.chi.il.us (Leslie Mikesell) (12/08/90)
In article <1CE00001.p376wj@tbomb.ice.com> time@tbomb.ice.com writes: >As an aside, my mail server recently tossed sendmail away for smail3. >This was because 30% of the mail I sent bounced going out, and 40% >of the replies never made it back. I am sure that had the sendmail >been configured a little more the problem could have been fixed. BUT >smail3 fixed the problem right away. It left the headers alone! Even smail3 will mung the the header lines by prepending its own uucp name if they are already in "!" notation. I ripped this part out because someone is likely to reverse user@domain into RFC976'ish domain!user when they pass the message off to uucp mailers. This would be reasonable (since reasonable uucp mailers treat the two forms interchangably) except that it encourages sites along the path to prepend their own name, and not all of them do. Thus the final recipient is likely to see x!y!domain!user where x is neither a neighbor nor a fully qualified domain. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/08/90)
In article <KARL.90Dec6171155@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >bruce@balilly.uucp writes: > > To: user@toaster To: toaster!user@gatebox > > From: me@tinytoy From: tinytoy!me@gatebox > > When a message crosses a domain boundary, all addresses must > be specified in the full format, ending with the top-level > name-domain in the right-most field. It is the responsibility > of mail forwarding services to ensure that addresses conform > with this requirement. In the case of abbreviated addresses, > the relaying service must make the necessary expansions... >The "gatebox" in question is doing exactly the right thing if it is >making addresses palatable to things outside your domain. If it's >doing it for destinations within your domain, it's harmless but not >especially useful. There's no evidence from those addresses that the internet was involved at all or that internet rules have any bearing on the matter. If it were harmless, the question wouldn't have been brought up. >If your site inflicts "user@tinytoy" on my sendmail, I'm going to >finish the job of address-breaking that your site started: It's going >to be rewritten as user@cis.ohio-state.edu. This rewrite does the >Right Thing in the usual case where Joe Random writes mail to, e.g., >jane@apple. I have to interpret OneWordHostNames within the context >of cis.ohio-state.edu, a host apple.cis.ohio-state.edu exists, and we >hide hostnames anyway, so I rewrite all OWHNs as cis.ohio-state.edu. The uunet practice of munging to OWHN%user@mydomain is probably the best approach to a bad situation. At least if you are willing to resolve OWHN's to the extent that they do (or throw it at Rutgers if you aren't). With this approach, if a site misinterprets the munging it will at least get an error locally instead of sending down something that appears to be a path as happens with the OWHN!user@mydomain approach. Actually, I contend that rewriting as user@OWHN.NET.mydomain would be a kinder thing to do if you have the wild-card MX to bring back the replies, and the NET name could be a variable telling you where to look for the OWHN to avoid conflicts. >Since a recipient here of address "user@tinytoy" couldn't have replied >directly to it anyway, I figure it serves 'em right if they have to >hunt through Received: headers for the real information they needed. But the recipient may not be at your site. If you claim uucp connectivity to tinytoy and toaster, then you should d*mn well be able to deliver from one to the other without destroying the header information. >I post an explanatory "mail/news/finger glitches and solutions" to a >local newsgroup periodically so that the users know what's what. Perhaps you should include such a message in error bounces when the destination was user@cis.ohio-state. Something like: "We regret that this message cannot be delivered - if this was a reply to a message from some other machine, we don't believe that machine ever existed." Les Mikesell les@chinet.chi.il.us
barnett@grymoire.crd.ge.com (Bruce Barnett) (12/08/90)
In article <1CE00001.p376wj@tbomb.ice.com> time@tbomb.ice.com (Tim Endres) writes: > Then, along came sendmail! The dark force of the mail universe! :^) > For some reason, which I have never had fully explained, sendmail > found it not only necessary to view headers to determine the means > of transporting the letter, but to modify these headers in order to > assist in the routing and reply routing of the letter through other > sendmails. The reason sendmail does this is because it is necessary. Not all addresses that come into our machine are valid. Not all are fully qualified domain names, or RFC822 addresses. The addresses user@machine or user@machine.UUCP are not valid Internet addresses. If I deliver mail to another internet site, it must be replyable. The above addresses are NOT. If we get such an address, and we send it to another internet site, we MUST convert it into the form: machine!user@crdgw1.ge.com To do anything else would be wrong. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
time@tbomb.ice.com (Tim Endres) (12/08/90)
In article <BARNETT.90Dec7152753@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > The reason sendmail does this is because it is necessary. > Not all addresses that come into our machine are valid. > Not all are fully qualified domain names, or RFC822 addresses. > > The addresses > > user@machine > or > user@machine.UUCP > > are not valid Internet addresses. If I deliver mail to another internet > site, it must be replyable. The above addresses are NOT. Reply-able? By what? If it is the user agent that incorrectly builds the reply address, then it is a bug in the user agent, and should be corrected by aliases or code fixes/extensions. If it is sendmail itself, the "envelope" that sendmail uses is sufficient to allow for reply (bounce?). Further, RFC822 allows for header extensions, with which sendmail could include any type of specification it desired, while retaining the integrity of the original header. > If we get such an address, and we send it to another internet site, we > MUST convert it into the form: > machine!user@crdgw1.ge.com This conversion can be done, and the delivery completed, without the modification of the mail's header. Do it in the sendmail "talk". If the conversion needs to be > To do anything else would be wrong. Or inconvenient? I do not profess to be an internet mail expert, I am not. I have simply always thought that the problems sendmial is "solving" could be solved while still observing the "do not touch the letter contents" rule. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
rickert@mp.cs.niu.edu (Neil Rickert) (12/08/90)
In article <1CE00001.914g2o@tbomb.ice.com> barnett@crdgw1.ge.com writes: > >Reply-able? By what? If it is the user agent that incorrectly builds >the reply address, then it is a bug in the user agent, and should >be corrected by aliases or code fixes/extensions. > Replyable by user software. I want my users to be able to hit the 'R' key to generate a reply with valid addresses extracted from the headers of the mail they are responding to. >This conversion can be done, and the delivery completed, without the >modification of the mail's header. Do it in the sendmail "talk". If >the conversion needs to be > Anything done which doesn't touch the headers obviously cannot fix broken headers. But it is the header address you are supposed to reply to. Some people are purists, and have a definition of perfection which is hardly ever met. Others of us just want mail to work, our users to be happy, and as little failed mail as possible. You can complain all you like about the idea that this should be done by the user agent, not the transfer agent. But if your user agent prepares bad addresses it is my users who suffer, and my time that has to be spent explaining to them how to prowl through the 'Received:' lines to try to construct a possibly valid address. And since users can create their own MUA with some shell scripts, you will never fix them all. But most mail goes through a single MTA, so correcting headers there is much more likely to be effective. >I do not profess to be an internet mail expert, I am not. I have simply >always thought that the problems sendmial is "solving" could be solved >while still observing the "do not touch the letter contents" rule. > Herein lies the crux of the argument. The argument that the MTA should not 'touch the letter contents'. This all depends on the definition of contents. If you just define the 'contents' to be everything below the header, then this is pretty well what happens. Part of the problem is with terminology such as 'Envelope' that has developed. This makes one think of a standard letter, with everything not in the envelope being the contents. This is an unfortunate way to look at it. Consider a priority mail which you are sending by Federal Express. Inside the package is the contents. On the outside of the package there is addressing information, receipts, etc. In addition the driver of the delivery truck has a check list he uses to keep track of what he is delivering. The 'envelope' of email really corresponds to the driver's checklist. The headers really correspond to what is on the outside of the package. The text below the headers correspond to the contents of the package. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
chip@tct.uucp (Chip Salzenberg) (12/11/90)
According to les@chinet.chi.il.us (Leslie Mikesell): >Even smail3 will mung the the header lines by prepending its own >uucp name if they are already in "!" notation. I ripped this part >out because someone is likely to reverse user@domain into RFC976'ish >domain!user when they pass the message off to uucp mailers. Of course, if a header field contains user@valid.domain.name, then any mailer mangling that header field into valid.domain.name!user is being Evil and Rude. In any case, you're quite right; Smail 3's behavior in prepending its host name is also Evil and Rude, and should be stopped forthwith. Perhaps a public patch posting would be appropriate. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "What's that thing, when people die, they take apart the body to see why?" -- St. Theresa of the Net
chip@tct.uucp (Chip Salzenberg) (12/11/90)
According to rickert@mp.cs.niu.edu (Neil Rickert): >Part of the problem is with terminology such as 'Envelope' that has >developed. This makes one think of a standard letter, with everything >not in the envelope being the contents. This is an unfortunate way to >look at it. Actually, I find the usage of "envelope" to refer to the external address information -- the From_ line, the argument to the remotely executed "rmail" command, the parameter of the MAIL FROM and RCPT TO line(s) of SMTP -- to be quite appropriate. They correspond quite nicely to the destination and return addresses on a first class letter. Where the Evilness and Rudeness of Sendmail comes in is when headers are modified ON THEIR WAY THROUGH to another site. For example, if you are unfortunate enough to send UUCP mail to someone via Sun.COM, you'll be in for a shock. Your To:, From: and Reply-To: addresses will be mangled into unusableness! Why? Because Sendmail modifies all headers on which it gets its grubby little fingers, no matter the message's final destination. Sendmail doesn't care where a message came from or where it's going. All headers are fair game. In my opinion, the header mangling "feature" of Sendmail is the worst thing to happen to E-Mail ever. Sendmail is an equal opportunity destroyer. If only I could go back and erase just that one disk at just the right time... -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "What's that thing, when people die, they take apart the body to see why?" -- St. Theresa of the Net
chip@tct.uucp (Chip Salzenberg) (12/11/90)
According to rickert@mp.cs.niu.edu (Neil Rickert): >A well designed 'sendmail.cf' will try to make sure that all addresses >are valid. If they are not valid, it will try to add routing to make sure >there is a valid internet address on the outgoing mail. If the incoming >address is already valid it is normally rewritten to its incoming form. This paragraph -- apparently written with a straight face -- brought to my mind this particularly appropriate quotation: This debate [over UUCP rerouting] is about whether any person can reliably know everything others know, want, and do. Some people believe the answer is yes. The rest of us are amazed. -- Vernon Schryver The Great Header Rewriting Debate breaks down along the same lines. No one can reliably know the form of all addresses that will be accepted as valid on another person's machine. If one neighbor site generates addresses that cannot be understood by another neighbor site, what business is that of yours? Correct answer: "None." -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "What's that thing, when people die, they take apart the body to see why?" -- St. Theresa of the Net
rickert@mp.cs.niu.edu (Neil Rickert) (12/11/90)
In article <27640C8A.1A46@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >The Great Header Rewriting Debate breaks down along the same lines. >No one can reliably know the form of all addresses that will be >accepted as valid on another person's machine. If one neighbor site >generates addresses that cannot be understood by another neighbor >site, what business is that of yours? Correct answer: "None." In principle, I agree. In practice ... I will get rid of all code in my version of sendmail that touches headers just as soon as: 1. Vendors stop creating and distributing software that routinely sends out mail with incorrect header addresses - usually headers with unqualified domain names. 2. All such broken software is replaced on existing machines. 3. UUCP addressing protocols are changed to fully support domain style addresses, and all UUCP users stop using bang addresses. Fat chance. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
chip@tct.uucp (Chip Salzenberg) (12/13/90)
According to rickert@mp.cs.niu.edu (Neil Rickert):
> In principle, I agree. In practice ...
No, wait. Perhaps I'm not making myself clear. Let me try again:
1. A message destined for delivery in *your* domain is fair game
for anything you may want to do, up to and including translating
the entire message, header and all, into Swahili.
2. A message passing through your domain on its way to my domain
should be left alone, without ANY modifications to the message
AT ALL except for the envelope.
(Note that "envelope" here means the SMTP "MAIL FROM" and "RCPT TO"
values, the argument to the UUCP "rmail" command, the From_ line,
and all other things that are *NOT* covered by RFC822.)
No site causes problems for its own users by following these rules.
No site causes problems for other sites by following these rules.
So why shouldn't we all adopt these rules right now? I'm listening...fair@Apple.COM (Erik E. Fair) (12/13/90)
In the referenced article, time@tbomb.ice.com writes: > >Disclaimer: I am no email guru, just been into it a long time. > [...] >I guess the bottom line is this: > I have *never* met a sendmail installation that did not create > problems by munging headers. This is a headache for the administrator > as much as the mail user. Now granted, it may be only one problem > out of thousands of letters, but sooner or later it happens. This is because there are entirely too many people who believe that because they have read chapter 5 of the Sendmail Installation and Operation Guide that they are qualified to modify sendmail configuration files. Wrong. You must have a deep understanding of the E-mail system as a whole, and how all the parts interact with each other (and there are some cases in which you just can't win, due to the ignorance of other mail system implementors. There is a special place in Hell for them). Sendmail is typical of most tools for UNIX: it gives you plenty of rope, with which you may accomplish your task, or hang yourself, if that is what you desire. Smail is a win for most people because it is simple, and has wired assumptions for common cases. Don't try anything complex with it, and it will serve you well. That was why it was designed. However, I wouldn't try to run a medium-complex mail installation (e.g. Apple Computer) without sendmail on the key systems because there are no alternatives with its power and flexibility, for those who are competant enough to make correct use of it. Erik E. Fair apple!fair fair@apple.com
rickert@mp.cs.niu.edu (Neil Rickert) (12/13/90)
In article <2766B2E7.276@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >1. A message destined for delivery in *your* domain is fair game > for anything you may want to do, up to and including translating > the entire message, header and all, into Swahili. > >2. A message passing through your domain on its way to my domain > should be left alone, without ANY modifications to the message > AT ALL except for the envelope. > >No site causes problems for its own users by following these rules. >No site causes problems for other sites by following these rules. >So why shouldn't we all adopt these rules right now? I'm listening... Sure. And when I relay Internet mail to 'uucpnode', and a user on 'uucpnode' does a R(eply), my machine gets to relay a lot of the uucpnode's local mail back to it, since that node doesn't understand the form of address on the header so sends it to its forwarding relay for interpretation. If I am going to follow this procedure I had better start charging real money for relay services. I will probably pick up quite a bit of cash just from this stupid 'local relaying'. But, come to think of it, as the money rolls in I should save it to pay for the lawyers. Some day the uucpsite admin is going to complain that with this improved service (of not munging headers) that I am charging him for, something funny is happening - he is not getting many replies to mail. Probably because all of those Internet sites having difficulty replying to 'uucpsite!user'. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
karl_kleinpaste@cis.ohio-state.edu (12/14/90)
chip@tct.uucp writes:
2. A message passing through your domain on its way to my domain
should be left alone, without ANY modifications to the message
AT ALL except for the envelope.
No site causes problems for other sites by following these rules.
So why shouldn't we all adopt these rules right now? I'm listening...
I doubt it. Pardon me for being rude, but I really doubt it.
A hypothetical example.
Let's assume that "tct" is a UUCP neighbor of "osu-cis." Let's assume
that chip@tct.uucp sends mail aimed at, say, osu-cis!ucbvax!somebody.
Headers read:
From: chip@tct.uucp
To: osu-cis!ucbvax!somebody
Envelope looks like "From tct!chip" and "rmail ucbvax!somebody" by the
time it reaches my system. So far, so good, I hope.
My mail installation wants to do things to reach ucbvax via the
Internet rather than UUCP. That is, seeing "ucbvax!somebody" as an
intended destination, I nonetheless want to speak SMTP to
ucbvax.berkeley.edu. This is perfectly legit, as the choice of
outbound transport is mine to make.
I _can't_ send
MAIL FROM:<tct!chip>
in SMTP because it lacks "@right.hand.side" as required by the RFCs.
MAISER on a DEC-20 will choke (has choked) on it. Nor can I send
MAIL FROM:<chip@tct.uucp>
as the envelope origin. "uucp" is not a valid top-level domain. See
RFC 1123 section 5.2.2 page 49.
I _can't_ send
From: chip@tct.uucp
in the headers. "uucp" is not a valid top-level domain. Similarly,
From: tct!chip
is insufficient due to no "@right.hand.side." See RFC 822 in several
places, such as the syntax grammar beginning section 4.1 page 17: the
"mailbox" spec must be properly dealt with.
Do you see a pattern developing here?
I hack headers as well as envelope because headers containing bogon,
unreal, and unregistered domains are invalid on the Internet. Your
headers, as supplied to my mailer, are WRONG. You CANNOT count on any
random site anywhere on the Internet being able to reply to such an
address. Keep in mind that, regardless of what envelope hacking gets
done, legitimate replies end up going to the From: address. And there
are rather more sites out there incapable of addressing "host!user"
than you might think.
I generate RFC-compliant headers when speaking to Internet sites. So
I will generate the following SMTP conversation to ucbvax.berkeley.edu
for this mail:
HELO something.cis.ohio-state.edu
MAIL FROM:<tct!chip@cis.ohio-state.edu>
RCPT TO:<somebody@ucbvax.berkeley.edu>
DATA
From: tct!chip@cis.ohio-state.edu
To: ucbvax!somebody@cis.ohio-state.edu
your text
.
QUIT
That works. Nothing else does. (Well, I could have rewritten the To:
as somebody@ucbvax.berkeley.edu, but my .cf isn't quite smart enough
to do that at that level.) And it was *necessary*.
--karlmcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) (12/14/90)
In article <KARL.90Dec13123956@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >Let's assume that "tct" is a UUCP neighbor of "osu-cis." Let's assume >that chip@tct.uucp sends mail aimed at, say, osu-cis!ucbvax!somebody. >Headers read: > From: chip@tct.uucp > To: osu-cis!ucbvax!somebody >Envelope looks like "From tct!chip" and "rmail ucbvax!somebody" by the >time it reaches my system. So far, so good, I hope. > >My mail installation wants to do things to reach ucbvax via the >Internet rather than UUCP. That is, seeing "ucbvax!somebody" as an >intended destination, I nonetheless want to speak SMTP to >ucbvax.berkeley.edu. This is perfectly legit, as the choice of >outbound transport is mine to make. > >I _can't_ send > MAIL FROM:<tct!chip> >in SMTP because it lacks "@right.hand.side" as required by the RFCs. >MAISER on a DEC-20 will choke (has choked) on it. Nor can I send > MAIL FROM:<chip@tct.uucp> >as the envelope origin. "uucp" is not a valid top-level domain. See >RFC 1123 section 5.2.2 page 49. I can't argue here, I agree, completely. >I _can't_ send > From: chip@tct.uucp >in the headers. "uucp" is not a valid top-level domain. Similarly, > From: tct!chip >is insufficient due to no "@right.hand.side." See RFC 822 in several >places, such as the syntax grammar beginning section 4.1 page 17: the >"mailbox" spec must be properly dealt with. But, I/chip/tct-admin PUT chip@tct.UUCP in the From: If I can't get a reply, THAT IS MY PROBLEM!!!!! If I want a reply bad enough I can do two things: a) Put the correct Reply-To: in. (and hope attention gets paid to it) b) Register my site under the appropriate valid top-level domain and get an MX record. Since I assume you'd prefer you have everyone do (b), why encourage the tct.UUCP people from being lazy, and in the meantime, possibly mangle the From: beyond recognition. Whenever someone asks me how to reply to a munged address, I tell them they can't. I have no problem telling people on an Internet site that they can't send to *.UUCP. And then explaining all the kludges a couple of minutes later. >I hack headers as well as envelope because headers containing bogon, >unreal, and unregistered domains are invalid on the Internet. Your My headers, above, are invalid. I await the rubber stamp of CA*net... -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so few cycles. mcr@julie.UUCP/michael@fts1.UUCP/mcr@doe.carleton.ca -- Domain address - Pay attention only to _MY_ opinions. - registration in progress.
rickert@mp.cs.niu.edu (Neil Rickert) (12/14/90)
In article <1990Dec14.064837.8996@Latour.Sandelman.OCUnix.On.Ca> fts1!latour!mcr@alfred.ccs.carleton.ca writes: >In article <KARL.90Dec13123956@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >>Let's assume that "tct" is a UUCP neighbor of "osu-cis." Let's assume >>that chip@tct.uucp sends mail aimed at, say, osu-cis!ucbvax!somebody. >>Headers read: >> From: chip@tct.uucp >> To: osu-cis!ucbvax!somebody >>... > > But, I/chip/tct-admin PUT chip@tct.UUCP in the From: > If I can't get a reply, THAT IS MY PROBLEM!!!!! > No, it is not JUST your problem. If someone finds they can't reply, they may look at the 'Received:' headers, and send mail to 'Postmaster@cis.ohio-state.edu' to ask for assistance. Karl doesn't need the extra work this will entail. If you want to send mail to 'ucbvax' and have an unrepliable 'From: ' header, that is your choice. All you need do is negotiate a uucp connection to ucbvax, and pay your own long distance charges. But if you prefer to use the services of another host to do your relaying you have a responsibility to make sure your headers conform to the standards of that relay host. And if you fail to meet that obligation, the relay host has every right to correct those header to ensure that they do meet its standards. Hell, just because you can drive in your own driveway without license plates, and can drive in my driveway without license plates, that doesn't mean you can use the highways all the way between your place and mine without using license plates. > If I want a reply bad enough I can do two things: > a) Put the correct Reply-To: in. (and hope attention gets paid to it) > b) Register my site under the appropriate valid top-level domain >and get an MX record. > > Since I assume you'd prefer you have everyone do (b), why encourage >the tct.UUCP people from being lazy, and in the meantime, possibly >mangle the From: beyond recognition. Correction - Karl does not mangle the headers beyond recognition. The headers emerge form tct.UUCP in a near unrecognizable form, and Karl modifies them to make them clearly and plainly recognizable. If what is on the 'From:' header is so precious to you, why don't you insert an additional copy in the body of the mail. Karl won't touch it there. > mcr@julie.UUCP/michael@fts1.UUCP/mcr@doe.carleton.ca -- Domain address Talking of munged addresses, why don't you fix this one. Otherwise some novice is going to send mail to it, with 3 '@' and two '/' symbols and all. (Yes, I am being serious. I have had to deal with users who have sent to exactly such strings as addresses). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
barmar@think.com (Barry Margolin) (12/15/90)
In article <1990Dec14.064837.8996@Latour.Sandelman.OCUnix.On.Ca> fts1!latour!mcr@alfred.ccs.carleton.ca writes: > But, I/chip/tct-admin PUT chip@tct.UUCP in the From: > If I can't get a reply, THAT IS MY PROBLEM!!!!! While it may be your bug, it is the other person's problem. He wants to send you a reply, and has to hunt down a mail guru to figure out how to address it. He can't even contact you to ask what the correct address is, unless he knows how to reach you by some medium other than email. Here's a situation that you haven't addressed: what if the message is going to multiple recipients, using different mail protocols having different address conventions. For instance, To: foo!bar!baz!user1, user2@quux.dom.ain Further, assume the baz system is on the UUCP network, so only understands UUCP bang-paths, while quux.dom.ain is on the Internet and only understands RFC-822 addresses. The same "From" field can't be used when forwarding the message to both addresses, because one of them won't be able to reply to it. Furthermore, one of the To addresses needs to be munged, because most user agents provide the option of including all the original recipients as secondary recipients of the reply. Sendmail is an application-level protocol-translating gateway. There wouldn't be much controversy over an SMTP<->X.400 gateway munging headers; it's an obvious part of the job. Why do you expect less of a UUCP<->SMTP gateway? The header requirements and interpretation mechanisms of the two protocols are not identical, and it is the job of a gateway to transform a message coming in via one protocol into a valid message for the other protocol. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
lear@turbo.bio.net (Eliot) (12/15/90)
mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) writes: >>I _can't_ send >> From: chip@tct.uucp >>in the headers. "uucp" is not a valid top-level domain. Similarly, >> From: tct!chip >>is insufficient due to no "@right.hand.side." See RFC 822 in several >>places, such as the syntax grammar beginning section 4.1 page 17: the >>"mailbox" spec must be properly dealt with. > But, I/chip/tct-admin PUT chip@tct.UUCP in the From: > If I can't get a reply, THAT IS MY PROBLEM!!!!! I disagree. You don't have to abide by the standards - the gateway site does. It is the gateway's responsibility to see that headers are conformant to the environment the message is about to enter. For example, it is Karl's responsibility to make sure that mail to Compuserv is conformant with their standards, not yours. > If I want a reply bad enough I can do two things: > a) Put the correct Reply-To: in. (and hope attention gets paid to it) > b) Register my site under the appropriate valid top-level domain >and get an MX record. (a) is pointless; you might as well substitute a proper from line. (b) is highly recommended. > Since I assume you'd prefer you have everyone do (b), why encourage >the tct.UUCP people from being lazy, and in the meantime, possibly >mangle the From: beyond recognition. I would think that when tct finds out that someone is mangling their from lines, they will do their best to correct the situation. To me, that is positive incentive towards fixing the problem. > Whenever someone asks me how to reply to a munged address, I tell >them they can't. I have no problem telling people on an Internet site >that they can't send to *.UUCP. And then explaining all the kludges >a couple of minutes later. This is negative incentive for change, exactly opposite of what you arguing for, above. Why should the people in .UUCP bother to fix themselves when others are continually finding new kludges to skirt around the brain damage? -- Eliot Lear [lear@turbo.bio.net]
les@chinet.chi.il.us (Leslie Mikesell) (12/15/90)
In article <1990Dec14.174541.14252@Think.COM> barmar@think.com (Barry Margolin) writes: >Sendmail is an application-level protocol-translating gateway. There >wouldn't be much controversy over an SMTP<->X.400 gateway munging headers; >it's an obvious part of the job. Why do you expect less of a UUCP<->SMTP >gateway? The header requirements and interpretation mechanisms of the two >protocols are not identical, and it is the job of a gateway to transform a >message coming in via one protocol into a valid message for the other >protocol. I think there will be controversy if the SMTP<->X.400 gateways can't invert the necessary mappings. That is, if one SMTP host sends to an X.400 forwarder who sends to another host that sends by SMTP to the destination and the headers are no longer usable. This appears to be the case that people are complaining about with the UUCP<->SMTP gateways. The munging necessary to keep the internet happy is not being done in a way that allows it to be undone at the other end, nor is there any way for the original munger to know what form the recipient wants (how, for example would you know that les@fb.com is 3 uucp hops off the internet and would greatly prefer to see From: les@chinet.uucp rather than From: chinet!les@some.domain?). The latter form is likely to undergo some very strange transformations along the way that you internet people never see. Les Mikesell les@chinet.chi.il.us
rickert@mp.cs.niu.edu (Neil Rickert) (12/15/90)
In article <1990Dec14.233316.11292@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >the UUCP<->SMTP gateways. The munging necessary to keep the internet >happy is not being done in a way that allows it to be undone at the >other end, nor is there any way for the original munger to know >what form the recipient wants (how, for example would you know >that les@fb.com is 3 uucp hops off the internet and would greatly >prefer to see From: les@chinet.uucp rather than > From: chinet!les@some.domain?). The latter form is likely to >undergo some very strange transformations along the way that >you internet people never see. There is absolutely nothing in the protocols, or in the behavior of 'sendmail' that would prevent you sending out your email as: From: les@chinet.uucp To: someone@somewhere ----------------------- Date: 10 BC. From: les@chinet.uucp To: someone@somewhere Subject: Whatever you feel like. The text of your message. ............... I guarantee that sendmail will not change the second set of 'headers'. And I am pretty sure your smart enough to quickly grind out a shell script or two that the recipient could use to delete the munged headers you don't like. Now what exactly is all this griping about? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
mrm@sceard.Sceard.COM (M.R.Murphy) (12/16/90)
In article <KARL.90Dec13123956@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >chip@tct.uucp writes: [the rewrite header argument deleted to save bandwith, such as it is...] If somebody sends you a message with bogus addressing from your view, bounce it back to them with a "This is bogus to me, please rewrite your freaking headers and re-try. Thank you so much.". Don't rewrite the headers. If you can't transport the way you want you are entirely within your rights and privileges to bounce the message. Re-write could be considered rude. Besides, it looks like the percentage of sites that can successfully rewrite is vanishingly small. Note that this is then a negative feedback system. The bouncee will either get the hint, will find another transport path, will stop sending mail, will install a better mailer, or will just enter an honest profession. I think all of this rewrite stuff is just people indirectly boasting that they can understand sendmail. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
lear@turbo.bio.net (Eliot) (12/16/90)
rickert@mp.cs.niu.edu (Neil Rickert) claims the following: > There is absolutely nothing in the protocols, or in the behavior of >'sendmail' that would prevent you sending out your email as: >From: les@chinet.uucp >To: someone@somewhere See RFC 1123 (in particular 5.2.18): ... o Some systems fail to fully-qualify domain names in messages they generate. The right-hand side of an "@" sign in a header address field MUST be a fully-qualified domain name. For example, some systems fail to fully-qualify the From: address; this prevents a "reply" command in the user interface from automatically constructing a return address. DISCUSSION: Although RFC-822 allows the local use of abbreviated domain names within a domain, the application of RFC-822 in Internet mail does not allow this. The intent is that an Internet host must not send an SMTP message header containing an abbreviated domain name in an address field. This allows the address fields of the header to be passed without alteration across the Internet, as required in Section 5.2.6. >Date: 10 BC. >From: les@chinet.uucp >To: someone@somewhere >Subject: Whatever you feel like. ... > I guarantee that sendmail will not change the second set of > 'headers'. Unless you are claiming that in fact your headers are in the ext of the message, this is all a matter of how one (mis)configures sendmail through either the cf (many bad ones floating around, out there) or through IDA, seismo, or other extensions. -- Eliot Lear [lear@turbo.bio.net]
les@chinet.chi.il.us (Leslie Mikesell) (12/17/90)
In article <1990Dec13.131236.25304@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > Sure. And when I relay Internet mail to 'uucpnode', and a user on >'uucpnode' does a R(eply), my machine gets to relay a lot of the >uucpnode's local mail back to it, since that node doesn't understand >the form of address on the header so sends it to its forwarding relay >for interpretation. I don't think I follow this. Can you give a real example? Do you mean a case where a message from the internet side includes CC: 's to others on the same uucp machine but with the internet addressing form so that mailx's <R> generates a name for the local machine that the MTA doesn't know about? > If I am going to follow this procedure I had better start charging real >money for relay services. I will probably pick up quite a bit of cash >just from this stupid 'local relaying'. There's nothing wrong with charging for services, but I can't imagine that the group reply problem would happen often enough to worry about. Certainly not often enough to do something that will break other software. For example if you change "user@domain" to site!usr and pass it on to a path where some of the hosts prepend their own uucp names to the line. In that case, the original would be usable but what they will receive may not be. (For direct neighbors this shouldn't make much difference). > Some day the >uucpsite admin is going to complain that with this improved service >(of not munging headers) that I am charging him for, something funny is >happening - he is not getting many replies to mail. Probably because >all of those Internet sites having difficulty replying to 'uucpsite!user'. If headers aren't munged, you will never see a From: uucpsite!user. The sending site would just use a local form (if any). As long as you can resolve the replies coming back through you, I see no problem with munging to user%site@your.domain but it would be a lot nicer if someone had thought about inverting the mappings before the standards were written. At least it's better than path!user@your.domain which is almost certain to be munged and/or interpreted incorrectly if it is forwarded off the internet (incorrectly isn't quite the right word since that type of address doesn't have a defined meaning outside of SMTP, but if I hand it to a program named "rmail" on a uucp machne, I wouldn't expect it to look past the first "!".) Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/17/90)
In article <1990Dec14.145021.2116@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > If you want to send mail to 'ucbvax' and have an unrepliable 'From: ' header, >that is your choice. All you need do is negotiate a uucp connection to >ucbvax, and pay your own long distance charges. In practice, this is seldom possible. How, for example, would I getting a link to the IBM hosts on BITNET where my users want to exchange mail? I suspect that if it were not for the internet, a standardized modem-based mail exchange facility would have been developed years ago. >But if you prefer to use >the services of another host to do your relaying you have a responsibility >to make sure your headers conform to the standards of that relay host. And >if you fail to meet that obligation, the relay host has every right to >correct those header to ensure that they do meet its standards. No one is complaing about how the package is bundled in transport, just about how it looks when delivered (and only one portion of the transport knows when delivery is complete). Les Mikesell les@chinet.chi.il.us
barmar@think.com (Barry Margolin) (12/17/90)
In article <1990Dec15.213806.26607@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >Note that this is then a negative feedback system. The bouncee will either get >the hint, will find another transport path, will stop sending mail, will >install a better mailer, or will just enter an honest profession. What world do you live in? The user has little of no control over what his mail system generates. All the bouncee will do is get frustrated. He may complain to his system vendor, and the vendor *might* fix it in the following release, and if he's lucky that will be as little as six months later. There's a good reason why people implement kludges. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
chip@tct.uucp (Chip Salzenberg) (12/18/90)
According to rickert@mp.cs.niu.edu (Neil Rickert): >In article <2766B2E7.276@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >> >>2. A message passing through your domain on its way to my domain >> should be left alone, without ANY modifications to the message >> AT ALL except for the envelope. >> > >Sure. And when I relay Internet mail to 'uucpnode', and a user on >'uucpnode' does a R(eply), my machine gets to relay a lot of the >uucpnode's local mail back to it, since that node doesn't understand >the form of address on the header so sends it to its forwarding relay >for interpretation. Assuming that the 'uucpnode' to which Mr. Rickert refers is a UUCP-only site that doesn't understand RFC822 addresses, then it is true by definition that an RFC822 address field will be unrepliable when it arrives at 'uucpnode.' However, the policy that Mr. Rickert supports -- pessimistically rewriting all mail headers for the greatest common denominator, namely, stock Unix /bin/mail -- disinfranchises all those UUCP sites who have registered domains under the Internet DNS. Furthermore, 'uucpnode' may not be the final destination of the message. It is not a good idea to assume anything about the final site based simply on the identity of the next hop in a bang path. I contend that rewriting "user@host.valid.domain" into "host.valid.domain!user" in the *header* is a Bad Thing because: 1. Any people who are exchanging mail with Internet sites had better understand RFC822 addresses, if only in their minds, or else they're not going to have much success anyway. 2. UUCP is only a transport. Sites which are fully compliant with all relevant Internet standards for E-Mail should not have their headers munged just because their mail is transported via UUCP. In other words, a site's choice of mail transport should not affect the address format. If unmunged mail headers result in bang-only sites having some problems with replying to mail, then I say: "Let them install smail." -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
rickert@mp.cs.niu.edu (Neil Rickert) (12/18/90)
In article <1990Dec16.203543.22769@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Dec13.131236.25304@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > >> Sure. And when I relay Internet mail to 'uucpnode', and a user on >>'uucpnode' does a R(eply), my machine gets to relay a lot of the >>uucpnode's local mail back to it, since that node doesn't understand >>the form of address on the header so sends it to its forwarding relay >>for interpretation. > >I don't think I follow this. Can you give a real example? Do you For example, you have the Internet name 'chinet.chi.il.us' and the UUCP name of 'chinet'. Your system is prbably set up well enough to recognize both names as local. But not all systems are. Suppose you didn't recognize 'chinet.chi.il.us' as local. Then if I leave 'To: les@chinet.chi.il.us' on the header, and you reply to all header addresses, your mailer wouldn't recognize the address as local so would send it back to a relay for reinterpretation. If you were a UUCP neighbor of mine, I would automatically rewrite 'chinet.chi.il.us' as 'chinet.UUCP' on all header destined for you, until I was sure you could properly recognize the address as local. >If headers aren't munged, you will never see a From: uucpsite!user. The Maybe that's true from your site, but not from others. >sending site would just use a local form (if any). As long as you >can resolve the replies coming back through you, I see no problem with >munging to user%site@your.domain but it would be a lot nicer if someone I sure hope they have changed it by now. But the last time I tried, mail addressed to user%site bounced with host unknown, while mail addressed to site!user went though. The site was not 'chinet', but it was bounced by either 'oddjob' or 'gargoyle', which are forwarders for your domain. >had thought about inverting the mappings before the standards were written. >At least it's better than path!user@your.domain which is almost certain >to be munged and/or interpreted incorrectly if it is forwarded off the >internet (incorrectly isn't quite the right word since that type of address >doesn't have a defined meaning outside of SMTP, but if I hand it to a program >named "rmail" on a uucp machne, I wouldn't expect it to look past the first >"!".) Hey, we agree. I wouldn't send 'path!user@my.domain' via rmail unless I knew that it would work for that host. I might send 'path!user', or 'myuucpname!path!user', but I don't mix '@' and '!' in an address using UUCP transport unless I have verified that they will be recognized correctly by the receiving domain. -------------- Actually, if 'chinet' were a UUCP neighbor, and sent mail for me to relay to Internet, I would rewrite 'From: les@chinet.UUCP' as one of 'From: chinet!les@mp.cs.niu.edu', or 'From: les%chinet.UUCP@mp.cs.niu.edu' or 'From: les%chinet@mp.cs.niu.edu'. But it would be my choice, not yours. (I believe I am currently using the second of these forms). However, since 'chinet' is not my UUCP neighbor, I rewrite 'From: les@chinet.UUCP' as 'From: les@chinet.UUCP'. The difference is that for my UUCP neighbors I have an obligation of making their addresses useable by Internet hosts, and of providing a route back to them. But for a UUCP address which is not a neighbor, I have no such obligation to provide a return route. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rickert@mp.cs.niu.edu (Neil Rickert) (12/18/90)
In article <1990Dec16.205033.23565@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >No one is complaing about how the package is bundled in transport, just >about how it looks when delivered (and only one portion of the transport >knows when delivery is complete). > This is really at the heart of the disagreement. The UUCP protocols do not specify a header. The Internet protocols do. If you don't like what Internet processing does, just design your mail software so that each message begins with '\n'. Then what you think of as header that should not be touched will really be part of the body where they will not be touched. The Internet forwarder you use will create some headers for you. The recipient domain can always discard all the Internet headers and the '\n' if it likes, and you will have an unchanged messaged at the receiving end, just as you want it. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
chip@tct.uucp (Chip Salzenberg) (12/18/90)
My original contention: > 2. A message passing through your domain on its way to my domain > should be left alone, without ANY modifications to the message > AT ALL except for the envelope. According to karl_kleinpaste@cis.ohio-state.edu: >I _can't_ send > MAIL FROM:<tct!chip> >in SMTP because it lacks "@right.hand.side" as required by the RFCs. > >I _can't_ send > From: chip@tct.uucp >in the headers. "uucp" is not a valid top-level domain. Similarly, > From: tct!chip >is insufficient due to no "@right.hand.side." Okay. I concede that Karl is right for the example he gives. Let me put forth two more examples, and see what would happen. 1. Let us suppose that the hypothetical machine "tct" with UUCP connection to "osu-cis" has just been registered under the domain TCT.COM. (I hope to do so shortly.) In that case, my hypothetical message will arrive at osu-cis with the envelope: From tct!chip but the header will be valid RFC822: From: chip@tct.com Will this header be rewritten into a bang path just because the mail came in from UUCP? I expect that it won't, since it's already RFC822. 2. (This is the example that sparked my original suggestion.) If mail from BAR.COM is being delivered to TCT.COM via UUCP from osu-cis, will the headers: From: foo@bar.com To: chip@tct.com be rewritten into bang paths just because my site's transport of choice is UUCP? This munging is *not* necessary. It is, in my opinion, rude to mung headers of UUCP sites which are cooperative enough to register with the DNS and comply with RFC822. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
chip@tct.uucp (Chip Salzenberg) (12/18/90)
According to barmar@think.com (Barry Margolin): > To: foo!bar!baz!user1, user2@quux.dom.ain > >Further, assume the baz system is on the UUCP network, so only understands >UUCP bang-paths ... The primary fallacy in this line of reasoning is the assumption that a site reachable via UUCP cannot deal with RFC822 addresses. >Sendmail is an application-level protocol-translating gateway. There >wouldn't be much controversy over an SMTP<->X.400 gateway munging headers; >it's an obvious part of the job. Why do you expect less of a UUCP<->SMTP >gateway? Because UUCP is just a transport. It doesn't have its own address format. Common implementations of mail over UUCP use the bang path as an envelope format, but the From:, To:, etc. lines can all be RFC822-compliant without any tribble -- er, trouble -- at all. Yes, bang paths in headers must be domainized before they are allowed to propagate across the Internet. But RFC822 messages need no munging at all to be propagated via UUCP. None at all. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) (12/18/90)
In article <1990Dec15.154618.7378@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > There is absolutely nothing in the protocols, or in the behavior of >'sendmail' that would prevent you sending out your email as: > >From: les@chinet.uucp >To: someone@somewhere > >----------------------- >Date: 10 BC. >From: les@chinet.uucp >To: someone@somewhere >Subject: Whatever you feel like. > > The text of your message. > > ............... > > I guarantee that sendmail will not change the second set of 'headers'. And Following this argument, NONE OF the headers are needed. I need only get the argument to rmail/SMTP RCPT TO: right. I have a question for Karl though (just to add some non-flame content to my message ;-) If you are MX'ing for someone for which you have a UUCP link with them, does it get turned into some.where.com!user@ohio-state.edu? No right? So if .UUCP went away, header munging would be a non-issue? UUCP would still be used as a transport agent though. Assuming that the uux/rmail interface was deemed to be bad, and one went the BSMTP route, would we then have lots of problems with the smart-host'ing being done (or have to do a massive coordination effort), or would source routes suddenly become popular again? I'm of the opinion that it is better to ship Unix without mail and assume that they can figure out Configure and make and install something, or to include a domain only version that also includes the .com/.us/.ca/etc. registration forms (for turnkey systems.) > Now what exactly is all this griping about? The simple desire to have From: lines left alone. If they MUST be rewritten, have the decency to rename the old header or something. -- :!mcr!: | The postmaster never | - Pay attention only Michael Richardson | resolves twice. | to _MY_ opinions. - HOME: mcr@sandelman.ocunix.on.ca + If that doesn't work, try: WORK: michael@fts.ocunix.on.ca + fts1!michael, mcr@doe.carleton.ca
les@chinet.chi.il.us (Leslie Mikesell) (12/18/90)
In article <47340@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: >However, I wouldn't try to run a medium-complex mail >installation (e.g. Apple Computer) without sendmail on the key systems >because there are no alternatives with its power and flexibility, for >those who are competant enough to make correct use of it. Have you investigated smail 3.1 (a very different thing than smail 2.5)? My impression (without much exposure to sendmail) is that it is more powerful than standard sendmail, especially in a uucp environment, but perhaps less flexible than sendmail + IDA. I'd like to see a real point by point comparison, though, if anyone has had the fortitude to tackle both in depth. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/18/90)
In article <1990Dec17.183615.3887@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > For example, you have the Internet name 'chinet.chi.il.us' >and the UUCP name of 'chinet'. Your system is prbably set up well >enough to recognize both names as local. But not all systems are. >Suppose you didn't recognize 'chinet.chi.il.us' as local. Then if I >leave 'To: les@chinet.chi.il.us' on the header, and you reply to all >header addresses, your mailer wouldn't recognize the address as local >so would send it back to a relay for reinterpretation. > If you were a UUCP neighbor of mine, I would automatically rewrite >'chinet.chi.il.us' as 'chinet.UUCP' on all header destined for you, until >I was sure you could properly recognize the address as local. Hmmm, I thought that the big argument for having a registered domain name was that it gave you an absolute address (i.e. interpreted the same everywhere). If the gateways are going to eat the names on the way out that concept sort of disappears. Besides, "real" uucp machines won't understand "machine.uucp" as their own names either. But, let's look at something a little more complicated, where the domain name actually hides many uucp hosts. For example I have set up fb.com through uunet, and everything destined for anyone@fb.com is actually delivered to uucp machine "afbf05" which happens to be a local call to uunet (D.C. area) but in fact most of the mail is destined for one of several machines in the Park Ridge IL area connected by a satellite link. All of the machines know how to resolve any variation of user@fb.com (just like a local address, everybody is in the aliases file), but it would clearly be wrong to change To: user@fb.com to user@afbf05.uucp when in fact the user isn't there. Delivery would not be affected of course, but you will force exactly the problem you are claiming to be fixing - if someone does a group reply it's going to bounce through the DC machine just to get back to the local host. >>If headers aren't munged, you will never see a From: uucpsite!user. The > Maybe that's true from your site, but not from others. True, but only because there is not a clear standard. Someone has gone out of their way to break things in the transport just to keep an already broken user agent happy. What's worse is that some sites do prepend their name and others don't, so that form is rarely usable anyway. I always use the uucp From_ line for replies which seems reliable with things that have come through uunet. Group replies are more problematic. > I sure hope they have changed it by now. But the last time I tried, >mail addressed to user%site bounced with host unknown, while mail addressed >to site!user went though. The site was not 'chinet', but it was bounced by >either 'oddjob' or 'gargoyle', which are forwarders for your domain. I don't doubt it and I suppose you really can't complain about '%' not working. But.... If you are doing the munging into user%site@your.domain it is your host that will be called upon to interpret the reply since you have guaranteed that it will come back through you. Thus it doesn't matter that others don't know how to resolve it (in fact it may be an advantage). >Actually, if 'chinet' were a UUCP neighbor, and sent mail for me to >relay to Internet, I would rewrite 'From: les@chinet.UUCP' as >one of 'From: chinet!les@mp.cs.niu.edu', or >'From: les%chinet.UUCP@mp.cs.niu.edu' or 'From: les%chinet@mp.cs.niu.edu'. >But it would be my choice, not yours. (I believe I am currently using the >second of these forms). What do you expect to happen when the "site!user@domain" form goes back off the internet down a path to a uucp destination? Say you get a message with a destination of fb.com or chinet.chi.il.us from your uucp neighbor. In the case of chinet, it will arrive with a couple of other hostnames prepended to the From: line making a correct interpretation impossible. In the case of fb.com it will look pretty much the way you write it but my machines deliberately interpret the !-path first to accomodate a broken (but not replacable) UA that generates group replies by making a path back to the sending machine prepended to the To: and CC: addresses. (But my reply to the sender will work anyway because it will use the uucp From_ line). >However, since 'chinet' is not my UUCP neighbor, I rewrite >'From: les@chinet.UUCP' as 'From: les@chinet.UUCP'. > The difference is that for my UUCP neighbors I have an obligation of making >their addresses useable by Internet hosts, and of providing a route back to >them. But for a UUCP address which is not a neighbor, I have no such >obligation to provide a return route. I would be a little more comfortable if this was worded more like: "I don't modify les@chinet.UUCP because I have no naming authority for chinet.UUCP." And this is precisely why I would like to see the uucp <-> internet gateway machines set up domain names solely for the purpose of mapping their uucp neighbors into convenient domain style names. In that case you would not only have the "authority" to map the names, you would be able to do it without undocumented or ambiguous kludges. Les Mikesell les@chinet.chi.il.us
rickert@mp.cs.niu.edu (Neil Rickert) (12/18/90)
In article <276D0D6A.6581@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to rickert@mp.cs.niu.edu (Neil Rickert): >>In article <2766B2E7.276@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>> >>>2. A message passing through your domain on its way to my domain >>> should be left alone, without ANY modifications to the message >>> AT ALL except for the envelope. >>> >> >>Sure. And when I relay Internet mail to 'uucpnode', and a user on >>'uucpnode' does a R(eply), my machine gets to relay a lot of the >>uucpnode's local mail back to it, since that node doesn't understand >>the form of address on the header so sends it to its forwarding relay >>for interpretation. > >Assuming that the 'uucpnode' to which Mr. Rickert refers is a >UUCP-only site that doesn't understand RFC822 addresses, then it is >true by definition that an RFC822 address field will be unrepliable >when it arrives at 'uucpnode.' > >However, the policy that Mr. Rickert supports -- pessimistically >rewriting all mail headers for the greatest common denominator, >namely, stock Unix /bin/mail -- disinfranchises all those UUCP sites >who have registered domains under the Internet DNS. > No where did you get the idea that I support "pessimistically rewriting all mail headers for the greats common denominator" -- I never said that, and I don't practice that. Just because I support the premise that at times they should be rewritten, don't jump to the conclusion that I always do so. For example, I have a UUCP neighbor, with uucp name of 'earth'. (This is NOT the earth.UUCP in the maps). If you send mail to say 'root@geol.niu.edu', and it arrives at my site with headers: To: root@geol.niu.edu From: chip@tct.uucp then it will be forwarded to earth!root with exactly the same headers. If, on the other hand, you address your message to 'root@earth.uucp' and it reaches my site, it won't finish up at the geology department at all - it will go the the 'earth.uucp' on the maps. Please don't jump to conclusions and put words in my mouth that I never said. >Furthermore, 'uucpnode' may not be the final destination of the >message. It is not a good idea to assume anything about the final >site based simply on the identity of the next hop in a bang path. > >I contend that rewriting "user@host.valid.domain" into >"host.valid.domain!user" in the *header* is a Bad Thing because: > If I see mail with a header address 'user@host.valid.domain', and I am forwarding it to a host which does not understand RFC822 addresses, I WILL rewrite that as 'host.valid.domain!user'. The fact that uucpnode may not be the final destination is AN IMPORTANT PART of the reason. For 'uucpnode' is very likely to blindly stick 'uucpnode!' in front of the address. This totally massacres the RFC822 format address, but does no serious harm to the form changed into bang notation. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rickert@mp.cs.niu.edu (Neil Rickert) (12/18/90)
In article <1990Dec18.071226.20809@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Dec17.183615.3887@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > >> If you were a UUCP neighbor of mine, I would automatically rewrite >>'chinet.chi.il.us' as 'chinet.UUCP' on all header destined for you, until >>I was sure you could properly recognize the address as local. > >Hmmm, I thought that the big argument for having a registered domain >name was that it gave you an absolute address (i.e. interpreted the >same everywhere). If the gateways are going to eat the names on the >way out that concept sort of disappears. Besides, "real" uucp machines >won't understand "machine.uucp" as their own names either. Serves me right for trying to save a few words. The address would actually be written to 'machine!user'. I DO want you to register a domain name. I want it so badly, that even if your software isn't ready for it you should do it, and I will transform the addresses so that you software doesn't need to deal with it. As I said, I will only convert headers to UUCP format until I know that your software is ready to deal with domain name formats. >But, let's look at something a little more complicated, where the domain >name actually hides many uucp hosts. For example I have set up >fb.com through uunet, and everything destined for anyone@fb.com is >actually delivered to uucp machine "afbf05" which happens to be a >local call to uunet (D.C. area) but in fact most of the mail is >destined for one of several machines in the Park Ridge IL area connected >by a satellite link. All of the machines know how to resolve any >variation of user@fb.com (just like a local address, everybody is in >the aliases file), but it would clearly be wrong to change To: user@fb.com >to user@afbf05.uucp when in fact the user isn't there. Delivery would >not be affected of course, but you will force exactly the problem you >are claiming to be fixing - if someone does a group reply it's going >to bounce through the DC machine just to get back to the local host. Yes, but if you domain is set up this way, it presumably CAN handle domain names. As I said, I will preserve domain name formatted headers to a uucp neighbor as soon as I know they are set up to handle them correctly. >>Actually, if 'chinet' were a UUCP neighbor, and sent mail for me to >>relay to Internet, I would rewrite 'From: les@chinet.UUCP' as >>one of 'From: chinet!les@mp.cs.niu.edu', or >>'From: les%chinet.UUCP@mp.cs.niu.edu' or 'From: les%chinet@mp.cs.niu.edu'. >>But it would be my choice, not yours. (I believe I am currently using the >>second of these forms). > >What do you expect to happen when the "site!user@domain" form goes back off >the internet down a path to a uucp destination? Say you get a message I expect the internet -> UUCP gateway to transform the address to 'site!user' if the gateway happens to be 'domain', and to transform it to 'domain!site!user' (or perhaps 'gateway!domain!site!user') otherwise. Most Internet to UUCP gateways do this, Chip Salzenberg to the contrary notwithstanding. In that case prepending another 'node!' by a site along the way doesn't totally massacre the address. >In the case of fb.com it will look pretty much the way you write it but >my machines deliberately interpret the !-path first to accomodate a >broken (but not replacable) UA that generates group replies by making >a path back to the sending machine prepended to the To: and CC: addresses. >(But my reply to the sender will work anyway because it will use the >uucp From_ line). Oh. You mean that while complaining about everyone else's software, you own software is hopelessly broken! > >>However, since 'chinet' is not my UUCP neighbor, I rewrite >>'From: les@chinet.UUCP' as 'From: les@chinet.UUCP'. >> The difference is that for my UUCP neighbors I have an obligation of making >>their addresses useable by Internet hosts, and of providing a route back to >>them. But for a UUCP address which is not a neighbor, I have no such >>obligation to provide a return route. > >I would be a little more comfortable if this was worded more like: "I don't >modify les@chinet.UUCP because I have no naming authority for chinet.UUCP." I don't rewrite 'les@chinet.UUCP' as 'les@chinet.chi.il.us' because I have no naming authority for chinet. I don't rewrite it as 'les%chinet.UUCP@mp.cs.niu.edu' because chinet is not my uucp neighbor so I have no obligation to provide a route. (Does that make you happier? I didn't think it would). If chinet were my neighbor, I would consider rewriting 'les@chinet.UUCP' as 'les@chinet.chi.il.us', but this would be a matter of discussion. I would not do such renaming if chinet objected. But in that case I would provide the extra routing. >And this is precisely why I would like to see the uucp <-> internet gateway >machines set up domain names solely for the purpose of mapping their >uucp neighbors into convenient domain style names. In that case you would >not only have the "authority" to map the names, you would be able to do >it without undocumented or ambiguous kludges. As pointed out by others, the name space for which I have authority to create names may not be an appropriate name space for my UUCP neighbors. This is a side effect of the organizational orientation of the Internet names. Had there instead been a purely geographical name allocation this would be easier. But organization name structure do have benefits, as your experience with 'fb.com' illustrates. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
barmar@think.com (Barry Margolin) (12/19/90)
In article <276D13B4.6732@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to barmar@think.com (Barry Margolin): >> To: foo!bar!baz!user1, user2@quux.dom.ain >>Further, assume the baz system is on the UUCP network, so only understands >>UUCP bang-paths ... >The primary fallacy in this line of reasoning is the assumption that a >site reachable via UUCP cannot deal with RFC822 addresses. Sorry, I should have said "and" instead of "so". Many UUCP sites only recognize bang paths. >>Sendmail is an application-level protocol-translating gateway. There >>wouldn't be much controversy over an SMTP<->X.400 gateway munging headers; >>it's an obvious part of the job. Why do you expect less of a UUCP<->SMTP >>gateway? > >Because UUCP is just a transport. It doesn't have its own address >format. Common implementations of mail over UUCP use the bang path as >an envelope format, but the From:, To:, etc. lines can all be >RFC822-compliant without any tribble -- er, trouble -- at all. UUCP is the name of a protocol *suite* (the transport layer protocols have names like "UUCP g-protocol"). Yes, RFC822-compliant messages are included in that suite, but there's no requirement that hosts using the UUCP mail transfer protocol recognize such addresses. They are expected to recognize almost-RFC822 messages that use bang paths, and to transform such headers en route (removing the current host from the beginning of destination paths, and adding it to the beginning of other paths). Part of the problem, of course, is that there is no precise specification of the requirements of UUCP hosts. The UUCP network is anarchistic, and that's what allowed it to grow so rapidly. But it also means that there is an enormous variety of implementations and versions out there, and it is frequently necessary to cater to common denominators. A gateway with only a few UUCP neighbors could probably have a database indicating which neighbors can handle RFC822 messages, and not mung the headers when forwarding there. But maintaining such a database for backbone sites with many neighbors is probably more work than most system administrators are willing to put up with (at many sites, support of the UUCP gateway is not a high priority, and is only tolerated by management so long as it doesn't impact the regular job). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jdeitch@jadpc.cts.com (Jim Deitch) (12/19/90)
In article <1990Dec18.045058.18758@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <47340@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: > >>However, I wouldn't try to run a medium-complex mail >>installation (e.g. Apple Computer) without sendmail on the key systems >>because there are no alternatives with its power and flexibility, for >>those who are competant enough to make correct use of it. > >Have you investigated smail 3.1 (a very different thing than smail 2.5)? >My impression (without much exposure to sendmail) is that it is more >powerful than standard sendmail, especially in a uucp environment, but >perhaps less flexible than sendmail + IDA. I'd like to see a real >point by point comparison, though, if anyone has had the fortitude >to tackle both in depth. > >Les Mikesell > les@chinet.chi.il.us You are partly right. Smail 3.1 is VERY nice, easy to configure, easy to maintain. Your normal system manager can have it running from source in about 2 hours. The hardest part is editing the config file. They even have a test configuration that you build, the system installs in a place you specify, then you can test it at your leisure. When you are satisfied that all is well, remake without the test config flag set and install. Real simple. Out of the box the configurations supplied will not have to be modified except for weird circumstances, arcnet, bsmtp over uucp, etc. My only gripe is that when using smtp you start it just like sendmail (sendmail -bd -q30m), but you need to have an entry in your cron file to check for mail that has been delayed and re-try delivery. Other than that, the documentation is good, it is easy to maintain, and bug-free. Just my 2 cents worth. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
les@chinet.chi.il.us (Leslie Mikesell) (12/19/90)
In article <1990Dec18.155353.5024@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>What do you expect to happen when the "site!user@domain" form goes back off >>the internet down a path to a uucp destination? > I expect the internet -> UUCP gateway to transform the address to >'site!user' if the gateway happens to be 'domain', and to transform it to >'domain!site!user' (or perhaps 'gateway!domain!site!user') otherwise. Most >Internet to UUCP gateways do this, Chip Salzenberg to the contrary >notwithstanding. In that case prepending another 'node!' by a site along the >way doesn't totally massacre the address. That's correct for the uucp "envelope" (From_ line and rmail destination of course, but it is as bad for my mailer to see something like that in the headers as it is for yours - would you do that to a local delivery? In any case, this doesn't seem to be handled consistantly. Some sites leave the site!user@domain form in the headers which is pretty much a disaster any way you look at it. Also, many sites will prepend their names in the headers *only* if there is already a "!" there. >>In the case of fb.com it will look pretty much the way you write it but >>my machines deliberately interpret the !-path first to accomodate a >>broken (but not replacable) UA that generates group replies by making >>a path back to the sending machine prepended to the To: and CC: addresses. >>(But my reply to the sender will work anyway because it will use the >>uucp From_ line). > > Oh. You mean that while complaining about everyone else's software, you >own software is hopelessly broken! Broken is kind of a harsh word - let's say the UA is optimized for relative addressing. It expects to find To: and Cc: addresses the way the sender wrote them and constructs group replies by using the From_ line to build a path back to the originating site, then tacking on whatever the sender used and optimizing away the redundent hops. From the uucp perspective that you *can't* know anything beyond your neighbors, that is the correct approach but of course alternate names for the same machines make it less than optimal. It is clear that this approach will not work at all though, if the addresses the sender put on the To: and Cc: lines have been altered in transport. In any case this particular UA (AT&T's PMX-mailers) has some functions that aren't available in anything else that I've seen (multiple binary attachments, versions that run on PC's with background communications, etc.) and I don't have source, so anything that needs to be fixed has to be done at the transport level. Also, I have to be able to continue to talk to the attmail service which wants and generates uucp-looking headers. Regarding your suggestion in another thread about putting an additional set of headers in the body portion of the message, this UA would be upset if anything touches the body. It inserts a Content-Length: header and expects to be able to use it to separate attachments. > As pointed out by others, the name space for which I have authority to >create names may not be an appropriate name space for my UUCP neighbors. >This is a side effect of the organizational orientation of the Internet >names. What I am suggesting is that you create a new domain solely for the purpose of establishing an organization where none currently exits. The intent of the organization would be to maintain sanity in the mail system. Les Mikesell les@chinet.chi.il.us
rickert@mp.cs.niu.edu (Neil Rickert) (12/19/90)
In article <1990Dec19.061836.8692@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Dec18.155353.5024@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> As pointed out by others, the name space for which I have authority to >>create names may not be an appropriate name space for my UUCP neighbors. >>This is a side effect of the organizational orientation of the Internet >>names. > >What I am suggesting is that you create a new domain solely for the >purpose of establishing an organization where none currently exits. >The intent of the organization would be to maintain sanity in the >mail system. > As long as you can plug your pocket calculator into a modem and instantly become part of the UUCP pseudo-network, no organization can possibly exist. If you want organization you need an enforced central registry, enforced standards, etc. But the current chaos has proved very productive - lets not break it just yet. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
mrm@sceard.Sceard.COM (M.R.Murphy) (12/19/90)
In article <1990Dec18.155353.5024@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: [...] > I expect the internet -> UUCP gateway to transform the address to >'site!user' if the gateway happens to be 'domain', and to transform it to >'domain!site!user' (or perhaps 'gateway!domain!site!user') otherwise. Most >Internet to UUCP gateways do this, Chip Salzenberg to the contrary >notwithstanding. In that case prepending another 'node!' by a site along the >way doesn't totally massacre the address. Prepend node! to the "From ", not to the "From: ". Don't mung valid RFC822 addresses. Bounce invalid RFC822 addresses if you feel like it. I think that it is a service and a long term favor to do so. Or let the site that doesn't understand the address bounce the message. Don't rewrite RFC822 addresses based on transport. That way prepending 'node!' doesn't massacre the address at all, since it isn't prepended. If it ends up being a real problem, and the communication is life or death, then there is always the telephone, which can be used to communicate to set up a direct mail connection :-) -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
les@chinet.chi.il.us (Leslie Mikesell) (12/20/90)
In article <1990Dec18.182210.12980@Think.COM> barmar@think.com (Barry Margolin) writes: >A gateway with only a few UUCP neighbors could probably have a database >indicating which neighbors can handle RFC822 messages, and not mung the >headers when forwarding there. Small sites like uunet perhaps??? Fortunately that is exactly the case there. They will send your choice of From: uunet!domain!user or user@domain. And they leave the To: lines pretty much the way the sender wrote them. Unfortunately it seems that not everyone knows how to rewrite the uucp From_ line independently from the From: header line. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/20/90)
In article <276D0D6A.6581@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >However, the policy that Mr. Rickert supports -- pessimistically >rewriting all mail headers for the greatest common denominator, >namely, stock Unix /bin/mail -- disinfranchises all those UUCP sites >who have registered domains under the Internet DNS. Actually, the original /bin/mail does not use anything in the headers nor does it even require headers to be present. Replies are constructed using the From_ line(s). Since error returns are virtually always sent back the envelope-from (the collapsed From_ line path) in uucp mail, a working mail connection requires this to generate a usable route back to the sender. This remains true regardless of any header munging - if you don't get a working envelope the connection is badly broken. The perverse systems that would be helped by munging are using a version of mailx that attempts to generate replies using the header From: but neither it nor the local transport understand the things that are likely to appear there if you have a link to systems bound by the requirements of RFC822. I contend that the envelope return should be used by uucp sites unless they are quite sure that the headers are always usable. Keep in mind that if this doesn't work, the sender isn't going to get any error message if he misspells the user name. >I contend that rewriting "user@host.valid.domain" into >"host.valid.domain!user" in the *header* is a Bad Thing because: > 1. Any people who are exchanging mail with Internet sites had > better understand RFC822 addresses, if only in their minds, > or else they're not going to have much success anyway. Not necessarily true. RFC976 style addressing works quite well (path!domain!user) to connect non-RFC822 uucp sites to ones that use domain addressing, as long as the relevant machines handle that form correctly. Thus the inversion doesn't really hurt anything (i.e. if your uucp site understands RFC822, it should also understand RFC976). The real problem is that this form is much more likely to have additional changes made to it as it is forwarded on to the destination. Still, if you build the replies from the envelope, it doesn't matter. The unresolved problem is what to do about group replies. Uucp demands relative addressing since you don't have a handy name service claiming to know every other machine in the universe. Thus you have to build routes in the context of the original sender - a goal that is at odds with absolute addressing. If you admit the existence of unregistered machines, then you have build the group addresses from the To: and Cc: lines by sending back to the originating machine and letting it interpret them. This is pretty much impossible if anyone has touched those headers before you get them. > 2. UUCP is only a transport. Sites which are fully compliant with > all relevant Internet standards for E-Mail should not have their > headers munged just because their mail is transported via UUCP. > >In other words, a site's choice of mail transport should not affect >the address format. Unfortunately that isn't the case, and I don't see anything that can be done about it at this point. Perhaps anyone who mungs the headers should be required to insert an X-Original-From: (etc.) so that the final delivery agent could put if back. Otherwise there is a serious loss of information. >If unmunged mail headers result in bang-only sites having some >problems with replying to mail, then I say: "Let them install smail." In my case, smail 2.5 would not have sufficed, because it does not pass NULL characters and I need a binary transparent transport. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/20/90)
In article <1990Dec18.152151.29598@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >If, on the other hand, you address your message to 'root@earth.uucp' >and it reaches my site, it won't finish up at the geology department at >all - it will go the the 'earth.uucp' on the maps. As it should. However, if that header line exists in a message that you pass over the internet, the information that you used to determine where it should be delivered will no longer exist. (At least if you re-write the site.uucp portion into something else). > If I see mail with a header address 'user@host.valid.domain', and I am >forwarding it to a host which does not understand RFC822 addresses, I WILL >rewrite that as 'host.valid.domain!user'. The fact that uucpnode may not >be the final destination is AN IMPORTANT PART of the reason. For 'uucpnode' >is very likely to blindly stick 'uucpnode!' in front of the address. This >totally massacres the RFC822 format address, but does no serious harm to the >form changed into bang notation. By itself, I see no problem with this. Handling domain!user and user@domain as fully equivalent makes perfect sense. However, the sites that prepend their own name may not be doing so blindly. They may in fact only do it when a "!" already exists in the header line. This is the case with smail 3 at least, but somewhere I recall seeing it mentioned that the reason was basically that most sendmail cf's handled it that way. Then the next site may not add their uucpname, and the recipient is left with an unqualified non-nieghbor site as the first hop in a path. Perhaps this isn't the case with your neighbors. Les Mikesell les@chinet.chi.il.us
rickert@mp.cs.niu.edu (Neil Rickert) (12/20/90)
In article <1990Dec19.162541.17566@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Unfortunately it seems that not everyone knows how to rewrite the >uucp From_ line independently from the From: header line. > We are finally down to a more justifiable complaint about sendmail. It is part of the design that the address rewriting for the envelope addresses also applies to the header addresses. And envelope addresses must be appropriate for the transport. The IDA versions of sendmail fix that. They allow separate address rewriting for header and for envelope. They also support a dbm database to efficiently choose how messages to a specific domain are handled. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
karl_kleinpaste@cis.ohio-state.edu (12/20/90)
chip@tct.uucp writes:
my hypothetical message will arrive at osu-cis with the envelope:
From tct!chip
but the header will be valid RFC822:
From: chip@tct.com
Will this header be rewritten into a bang path just because the mail
came in from UUCP? I expect that it won't, since it's already RFC822.
Any header of the form localpart@some.reasonable.domain (which
specifically does not include .uucp) will be left entirely unmolested.
My sendmail.cf will notice the proper form, and immediately depart the
ruleset without modifying the address. (Or, perhaps more precisely,
it will rewrite it in exactly the form in which it was found. Either
way, a semantically null operation.)
2. (This is the example that sparked my original suggestion.) If
mail from BAR.COM is being delivered to TCT.COM via UUCP from osu-cis,
will the headers:
From: foo@bar.com
To: chip@tct.com
be rewritten into bang paths just because my site's transport of
choice is UUCP?
Again, since it's in The Right Form, I don't touch it. If what I got
was rather more complex (e.g., host!user@some.domain), then some
rewrites may be necessary as the message departs via UUCP to avoid the
imaginary ambiguity of @-vs-! precedence, but I never mess with pure
user@dom.ain syntax.
--karlkeld@login.dkuug.dk (Keld J|rn Simonsen) (12/20/90)
chip@tct.uucp (Chip Salzenberg) writes: >However, the policy that Mr. Rickert supports -- pessimistically >rewriting all mail headers for the greatest common denominator, >namely, stock Unix /bin/mail -- disinfranchises all those UUCP sites >who have registered domains under the Internet DNS. >Furthermore, 'uucpnode' may not be the final destination of the >message. It is not a good idea to assume anything about the final >site based simply on the identity of the next hop in a bang path. What we do here is that we rewrite the headers in agreement with each uucp site connected to us (we have over 100 uucp sites connected). We have then a collection of Sendmail mailer specifications, indicating rewriting and other things such as character set of the mail body. Then we use the IDA sendmail "mailertable" file to specify in site basis these mailers. So we normally do quite some things to the mail itself. We normally domainizise the uucp address - put it into proper Intenet replyable addresses when receiving mail from a Danish uucp site, and maybe convert headers into some bangified address when sending mail to the uucp site. And then we convert the body to the agreed character set, such as ASCII, Danish ASCII, ISO 8859-1, IBM CP 850 or 60 other character sets. Keld Simonsen
chip@tct.uucp (Chip Salzenberg) (12/21/90)
According to rickert@mp.cs.niu.edu (Neil Rickert): >No where did you get the idea that I support "pessimistically rewriting >all mail headers for the greats common denominator" -- I never said that, >and I don't practice that. Well, I apologize for jumping to conclusions. Having read further messages from Mr. Rickert, I see that he refuses to rewrite addresses that arrive via UUCP unless the host part of the address specifies one of his neighbor sites. I have no objection to this policy. On the other hand, Mr. Rickert also writes: >If I see mail with a header address 'user@host.valid.domain', and I am >forwarding it to a host which does not understand RFC822 addresses, I WILL >rewrite that as 'host.valid.domain!user'. The fact that uucpnode may not >be the final destination is AN IMPORTANT PART of the reason. For 'uucpnode' >is very likely to blindly stick 'uucpnode!' in front of the address. Let's analyze the situation described here. As a message moves from site to site via UUCP, each site's mailer can (1) understand or (2) not understand RFC822. In the first case -- a "smart uucp" site -- the mailer will recognize valid RFC822 addresses and leave them alone. This is so because a properly configured Sendmail will only prepend "host!" to an address that already contains a bang. (Note that sites with broken Sendmail configurations are not a valid excuse to mangle headers. They may be a pain, but they're not an excuse.) In the second case -- a "dumb uucp" site -- the mailer will not know that the RFC822 headers even exist, since it is concerned only with the message envelope. It therefore will not prepend "host!" to the RFC822 addresses in the header. Therefore, according to the preceding analysis, there is no reason ever to rewrite a valid RFC822 address into a bang path. What have I missed? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
chip@tct.uucp (Chip Salzenberg) (12/21/90)
According to les@chinet.chi.il.us (Leslie Mikesell): >Actually, the original /bin/mail does not use anything in the >headers nor does it even require headers to be present. I knew the /bin/mailx story. Blaming /bin/mail was a thinko. Sorry. >The perverse systems that would be helped by munging are using >a version of mailx that attempts to generate replies using the >header From: but neither it nor the local transport understand >the things that are likely to appear there if you have a link >to systems bound by the requirements of RFC822. Yes, well, mailx is broken, isn't it? To my knowledge, the very existence of the From: header is an Internet (i.e. RFC822) invention. So a mailer that uses From: but can't deal with RFC822 is simply brain dead. More to the point, it is not a valid excuse for munging everyone else's headers. Before flaming me for this point of view, please remember that Mush and Elm are freely available and are good enough to be used as replacements for mailx. >I contend that the envelope return should be used by uucp sites >unless they are quite sure that the headers are always usable. Well, that's great, unless replies are to be routed according to a local paths database, like here. So we use Reply-To: and From:. Unfortunately, due to the header munging I decry, I found it necessary to add to Elm a "domainize" feature, which converts "x!y!z" to "z@y". I don't consider this Rabid Rerouting, incidentally, because it is done in the User Agent at user request. >>I contend that rewriting "user@host.valid.domain" into >>"host.valid.domain!user" in the *header* is a Bad Thing because: >> 1. Any people who are exchanging mail with Internet sites had >> better understand RFC822 addresses, if only in their minds, >> or else they're not going to have much success anyway. > >Not necessarily true. RFC976 style addressing works quite well >(path!domain!user) to connect non-RFC822 uucp sites to ones >that use domain addressing, as long as the relevant machines >handle that form correctly. Note that I said "people", not "mailers". The *people* at that site will see Usenet signatures that say "user@valid.domain", and they will eventually learn the meaning of that address form and will learn the local incantation for sending mail to such an address. So since people have to deal with domain addresses from signatures and business cards, I see no problem with asking them to do the same for addresses found in Reply-To: headers. >>In other words, a site's choice of mail transport should not affect >>the address format. > >Unfortunately that isn't the case, and I don't see anything that can >be done about it at this point. Forgive me, but I don't see that this statement has any supporting evidence. Surely it doesn't assert that a UUCP-based mail link is incapable of complying with RFC822? >In my case, smail 2.5 would not have sufficed, because it does not >pass NULL characters and I need a binary transparent transport. Sending non-ASCII in a mail message is just asking for trouble. And I don't mean only from UUCP mailers. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
chip@tct.uucp (Chip Salzenberg) (12/21/90)
According to barmar@think.com (Barry Margolin): >UUCP is the name of a protocol *suite* (the transport layer protocols have >names like "UUCP g-protocol"). Yes, RFC822-compliant messages are included >in that suite, but there's no requirement that hosts using the UUCP mail >transfer protocol recognize such addresses. As I noted at length in another message, the "dumb UUCP" sites about which everyone seems so worried won't even notice that the RFC822 headers exist, because dumb UUCP sites *only* care about the envelope. It is a known and acknowledged fact that dumb UUCP sites require bang paths in the envelope. Rewriting the envelope is therefore required. No problem. So what does that have to do with RFC822 headers? Nothing, that's what. Munging addresses in *headers* just because dumb UUCP sites need bang paths in the *envelope* is misdirected at best. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
brian@ucsd.Edu (Brian Kantor) (12/21/90)
Our rmail has been taught to believe that any bangist address in a From: line arriving via uucp is likely to be wrong, so it substitutes the From_ path in place of it. It also does that if there is no domain, the domain is "uucp", or there is no From: line. This is passed to sendmail, which converts the bangist path in the arriving From: line to bangist!path@ucsd.edu (RFC822 compliant) for internal processing, which is unaltered when the mail is sent out via an SMTP connection, and which is converted to ucsd!bangist!path when the mail is forwarded using uucp. If the mail arriving via uucp contains a From: line like host@dom.ain, rmail does not alter it at all before passing it to sendmail, and when it leaves via uucp, we choose the greatest common denominator and issue it as ucsd!dom.ain!host in the outgoing From: line, and as "From dom.ain!host date remote from ucsd" in the uucp From line. This provides the most widely-usable form of headers for people forwarding mail through us. It may thwart some attempts to use magic routers for uucp (some cope, some don't), but few of our uucp connections run them, since we provide that service. I find this to be a good set of compromises, and on the whole, satisfactory. Brian Kantor UCSD Postmaster brian@ucsd.edu BRIAN@UCSD ucsd!brian
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/21/90)
On 13 Dec 90 17:39:56 GMT, karl_kleinpaste@cis.ohio-state.edu said:
kleinpaste> chip@tct.uucp writes:
chip> 2. A message passing through your domain on its way to my domain
chip> should be left alone, without ANY modifications to the message AT
chip> ALL except for the envelope.
chip> No site causes problems for other sites by following these rules.
chip> So why shouldn't we all adopt these rules right now? I'm
chip> listening...
kleinpaste> I doubt it. Pardon me for being rude, but I really doubt
kleinpaste> it. A hypothetical example. Let's assume that "tct" is a
kleinpaste> UUCP neighbor of "osu-cis." Let's assume that chip@tct.uucp
kleinpaste> sends mail aimed at, say, osu-cis!ucbvax!somebody. Headers
kleinpaste> read:
kleinpaste> From: chip@tct.uucp
kleinpaste> To: osu-cis!ucbvax!somebody
kleinpaste> Envelope looks like "From tct!chip" and "rmail
kleinpaste> ucbvax!somebody" by the time it reaches my system. So far,
kleinpaste> so good, I hope.
No, nothing good. Your hypothetical geek is using two different and
incompatible addressing formats in a message. Is the message intended to
be RFC822 compliant? If so, the "To:" line is not. Is it intended to be
UUCP compliant? If so, anything goes (UUCP mail only cares about the
envelope), but then he guy is not expecting to be replied to for real,
as the From: line is bogus from a UUCP point of view. He would force an
UUCP target to use the 'From ' line to reply. If he used a proper UUCP
relative name such as 'From: seismo!tct' things would be ok instead.
Note: let me repeat that not a lot of people realize that in the UUCP
world addresses and routes are not the same thing; UUCP uses relative
names, that is a site name is given as 'a!b!c' which means 'the c
machine which a neighbour of b, which is a neighbour of a'. Given UUCP
maps one can well devise a completely different route to *that* 'c',
that does not pass thru 'a' or 'b'. This is why 'From: ' and 'From '
(and 'Reply-To: ') in UUCP mail can specify completely different bang
sequences.
kleinpaste> My mail installation wants to do things to reach ucbvax via
kleinpaste> the Internet rather than UUCP. That is, seeing
kleinpaste> "ucbvax!somebody" as an intended destination, I nonetheless
kleinpaste> want to speak SMTP to ucbvax.berkeley.edu. This is
kleinpaste> perfectly legit, as the choice of outbound transport is mine
kleinpaste> to make.
Not so easy! First you must prove that ucbvax and ucbvax.berkely.edu are
the same entity. Granted that you do that, you now have the problem of
*you* deciding to become a gateway between the UUCP and the Internet
world. This is *your* problem, as the originator of your piece of mail
cannot possibly anticipate it. As a gateway it is *your* problem to
preserve semantics. You get a patched up solution:
kleinpaste> I generate RFC-compliant headers when speaking to Internet
kleinpaste> sites. So I will generate the following SMTP conversation
kleinpaste> to ucbvax.berkeley.edu for this mail:
kleinpaste> HELO something.cis.ohio-state.edu
kleinpaste> MAIL FROM:<tct!chip@cis.ohio-state.edu>
kleinpaste> RCPT TO:<somebody@ucbvax.berkeley.edu>
kleinpaste> DATA
kleinpaste> From: tct!chip@cis.ohio-state.edu
kleinpaste> To: ucbvax!somebody@cis.ohio-state.edu
kleinpaste> your text
kleinpaste> .
kleinpaste> QUIT
kleinpaste> That works. Nothing else does.
I agree it works, *as things are now*, but it is disgusting. The real
problem is that, let me repeat it for the millionth time, the UUCP and
Internet naming structures are totally different, and there is no good
way to map one onto the other in all cases, so a gateway to/from the
Internet cannot guarantee to preserve semantics.
The real solution is not to attempt to do this, like you do above, but
to introduce in the Internet a way of addressing entities outside the
Internet naming structure.
That is, the real problem is simply that the Internet standards do not
provide for mail gateways, so if poor Kleinpaste of Ohio state is good
enough to provide one, he has to pretend that certain things are
Internet addresses, because the Internet is a closed system (as far as
standards make it), when they are not, and this causes endless trouble.
Note that this is pure Internet parochialism; since UUCP uses relative
naming and quasi-source routing, UUCP mail can easily accomodate any
other naming scheme that does not exclamation marks in its addresses.
As fas as I remember, you said that for precisely this reason Ohio's
sendmail translates all addresses internally to UUCP bang notation and
then reconverts them to Internet if necessary at the last moment if
needed. Is is too late to switch the Internet to bang notation, at least
for naming (not for routing)? I am afraid it is. But it is not too late
to add some decent extension to the headers to handle this.
Many will recognize my style when I say that your solution should be
rewritten as:
HELO something.cis.ohio-state.edu
MAIL FROM:<uucp-gateway@cis.ohio-state.edu>
RCPT TO:<somebody@ucbvax.berkeley.edu>
DATA
Sender: uucp-gateway@cs.ohio-state.edu
Apparently-To: somebody@ucbvax.berkeley.edu
From: chip@tct.uucp
To: osu-cis!ucbvax!somebody
your text
.
QUIT
Note, note that I am not sure about adding 'Apparently-To: ', a bit more
about 'Sender: '; and note that the 'To: ' is *unchanged*, because it is
not a route (routes belong to envelopes!), it is a relative address. The
'From: ' is also unchanged, of course!
What about a nice RFC that standardizes ways of addressing entities
beyond a gateway between the Internet and the DNS and the
something-that-lurks-malignantly-in-the-dark-night-outside?
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukles@chinet.chi.il.us (Leslie Mikesell) (12/22/90)
In article <1990Dec19.124545.26165@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > As long as you can plug your pocket calculator into a modem and instantly >become part of the UUCP pseudo-network, no organization can possibly exist. >If you want organization you need an enforced central registry, enforced >standards, etc. Well, X.400 promises to give us a system complicated enough that only large organizations will be able to use it. If that is the goal, all we have to do is wait. I'm trying to propose an alternative to an enforced central registry with a central standard enforcing "lowest common denominator" standards. That alternative is for certain sites to act as hubs, allowing ad-hoc communications on either side and providing gateway services as needed. This makes it trivial to add and delete sites since only the local hub needs to know about it, and gives a certain degree of freedom to the sites local to each hub. That physical organization already exists around internet <-> uucp gateway sites. Making the organization logical as well seems like it would be a good thing for all concerned. > But the current chaos has proved very productive - lets not break it just yet. As the ratio of computers to users approaches 1:1 the current system will break all by itself. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/22/90)
In article <1990Dec19.154652.11573@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >Prepend node! to the "From ", not to the "From: ". Don't mung valid RFC822 >addresses. Bounce invalid RFC822 addresses if you feel like it. I think that it >is a service and a long term favor to do so. Or let the site that doesn't >understand the address bounce the message. Don't rewrite RFC822 addresses based >on transport. That way prepending 'node!' doesn't massacre the address at all, >since it isn't prepended. In mail from mrm@Sceard.COM I received a copy of the headers from a message I had sent to him earlier. I know that the From: line left chinet looking like: From: les@chinet.chi.il.us (Leslie Mikesell) What he got was: From: Leslie Mikesell <ucsd!gargoyle.uchicago.edu!chinet.chi.il.us!les> Are we having fun yet? >If it ends up being a real problem, and the communication is life or death, then >there is always the telephone, which can be used to communicate to set up a >direct mail connection :-) Not always - you may want to mail to a site where modems aren't available (or allowed) or you may have no common communications protocol. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/22/90)
In article <27710AE7.1356@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>I contend that the envelope return should be used by uucp sites >>unless they are quite sure that the headers are always usable. >Well, that's great, unless replies are to be routed according to a >local paths database, like here. So we use Reply-To: and From:. In practice, it should be pretty rare that the recipient's response should go a different route than an error return. If the Reply-To: is munged as well and you want to use it, then you have a problem. Using !-notation for the addressing is not at odds with paths routing, though. >Unfortunately, due to the header munging I decry, I found it necessary >to add to Elm a "domainize" feature, which converts "x!y!z" to "z@y". >I don't consider this Rabid Rerouting, incidentally, because it is >done in the User Agent at user request. I'm not arguing *for* header munging - I don't think any host should prepend their own name to the header lines. But if it were not for encouraging that practice I wouldn't object to the domain!user re-write. >Forgive me, but I don't see that this statement has any supporting >evidence. Surely it doesn't assert that a UUCP-based mail link is >incapable of complying with RFC822? Given the proper support software there is no particular problem in delivering to domain style addresses and assuming you have a registered domain name there is no problem in putting it in the From: line. The place where the philosophical difference arises is when you want to generate a group-reply from the To: and Cc: lines. The domain philosophy says that the addresses are absolute and can be simply extracted and used as-is (assuming they haven't been modified in transport). The uucp philosophy says that addresses are relative to the sender and are only valid in the sender's context. So, my mailer will happily deliver a message like so: To: attmail!somewhere!someone Cc: someone@machine.bitnet Can anyone's mailer handle a group reply to that? >>In my case, smail 2.5 would not have sufficed, because it does not >>pass NULL characters and I need a binary transparent transport. >Sending non-ASCII in a mail message is just asking for trouble. And I >don't mean only from UUCP mailers. No, it's asking to save non-trivial amounts of money by not having to ascii-ize everything, not to mention training everyone involved to know the difference between ascii and non-ascii. A seat-of-the pants guess is that it would raise our phone bills about $10K/year if everything that is being sent as attachments grew by a third from being encoded. I'd say that not being able to deliver whatever the mail transport receives is asking for trouble and will force you to either work around the limitations or provide an alternative service. Les Mikesell les@chinet.chi.il.us
barmar@think.com (Barry Margolin) (12/22/90)
In article <1990Dec21.193938.29940@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In practice, it should be pretty rare that the recipient's response >should go a different route than an error return. You contradict this later in the same message: >The place where the philosophical difference arises is when you want >to generate a group-reply from the To: and Cc: lines. Which, in my experience, is extremely common. Most of the users here have their UA's reply command configured to do this by default. Another case that may be common in some organizations is a secretary sending mail for the boss; the envelope return address and the 822 Sender: field should be the secretary, but the From field should be the boss. Finally, mailing list exploders should arrange for error messages to go to the maintainer of the list, but replies should go to the author of the message. At various times during this discussion Post Office analogies have been used, so here's another (somewhat imperfect) one: the closest analogy to the email envelope is the PO's postmark. The From field is like the return address, the Reply-To field is the inside address, and the Sender field is the secretary's initials below the closing. > The domain >philosophy says that the addresses are absolute and can be simply >extracted and used as-is (assuming they haven't been modified in >transport). The uucp philosophy says that addresses are relative >to the sender and are only valid in the sender's context. So, >my mailer will happily deliver a message like so: > To: attmail!somewhere!someone > Cc: someone@machine.bitnet > >Can anyone's mailer handle a group reply to that? Only if the bang path is updated whenever the message is forwarded. A day or so ago, someone (maybe you) mentioned that pure UUCP hosts will only look at the From_ field. The reality is that few hosts are "pure UUCP". Most hosts using UUCP mail transport also have generic mail user agents (MH, MUSH, Emacs RMAIL, etc.). Because of the mix of protocols being used, most of these will recognize many different mail formats, and try to deal with them sensibly. If the message looks roughly like RFC-822 format they'll handle it; the UA rarely needs to parse the address portion of a header, all it has to do is hand it to the system's MTA. So, even though the To field in the above example is invalid 822 format there's no reason for a UA to mind; the UA expects the MTA to deliver messages containing addresses that it is willing to have returned to it. >>Sending non-ASCII in a mail message is just asking for trouble. And I >>don't mean only from UUCP mailers. >I'd say that not being able to deliver whatever the mail transport >receives is asking for trouble and will force you to either work >around the limitations or provide an alternative service. I don't know about UUCP mailers, but RFC-821 mailers are definitely text-only. Newlines are required to be converted to a standard format so that mail can be sent between systems with differing newline conventions, and not all such transformations are perfectly invertible. This is the reason the FTP protocol has an explicit command to perform binary transfers. RFC-821 also allows MTA software that has a fixed-size input line buffer by imposing a maximum line length (256 characters, I think). RFC-821 was designed for transfer of text mail; there are other protocols being developed to solve the more general problem. You can hammer a nail with a screwdriver, but don't complain to the screwdriver manufacturer if it's not easy. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
blarson@blars (12/22/90)
In article <25215@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: >Our rmail has been taught to believe that any bangist address in a From: >line arriving via uucp is likely to be wrong, so it substitutes the From_ >path in place of it. It also does that if there is no domain, the >domain is "uucp", or there is no From: line. Therefore breaking any mail message that purposly put a differnt evalope "From" (actually return) address. Mailing lists should put the moderator address in the envalope for bounce messages (broken bitnet mailers don't use this for the designed purpouse) and leave the From: and Reply-To: fields alone, so users can easily reply to the actual message sender. (Error-to: is an unneeded sendmail inovation which hopefully hasn't been duplicated elsewhere.) -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
brian@ucsd.Edu (Brian Kantor) (12/23/90)
In article <151@blars> blarson@blars writes: >Therefore breaking any mail message that purposly put a differnt >evalope "From" (actually return) address. Mailing lists ... True (more or less), except that there is no capability in UUCP to have two addresses - there is only ONE from address, and that's the "remote from" line at the front of the message. Remember that a uucp site may ignore, correctly update, or hopelessly damage the From: line in mail headers (since it's not part of the transport spec), whereas the "remote from" is going to be correct. We don't fiddle RFC821 (SMTP) messages that way. The two-address scheme works just fine there. And we use it for all the many mailing lists we host here. BTW, why doesn't the From: line in your posting have a domain? "blarson@blars" isn't replyable from outside yours, you know. - Brian
oc@vmp.com (Orlan Cannon) (12/23/90)
In article <27710D99.140E@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >Munging addresses in *headers* just because dumb UUCP sites need bang >paths in the *envelope* is misdirected at best. This is indeed the crux of the matter. Intelligent munging of envelopes is considered "a good thing". The problem is with MUAs that insist on using RFC822 headers for replies but are distributed with MTAs that know nothing about RFC822 (or 976 or 1123, for that matter). AT&T, are you listening? Mailx knows about RFC822 headers and replies to the "From:" line. It passes the message to /bin/mail, which thinks it must be a strange local address... Munging the headers is just a defensive tactic against AT&T's errors. The fact that semi-intelligent MUAs and MTAs are freely available, at no cost, is avoiding the fact that most computer installations don't want to think about it. They don't want to have to install smail or elm or mush. They bought the system and that's that. The answer is to talk to your UUCP neighbors. Ask what kind of MTA or MUA they use. Mung the headers accordingly. Don't make a universal rule of it. We've got plenty of universal rules that work just fine. Local exceptions are *OK*. As long as *you and your neighbor* know what you're doing. Talking about it on the net doesn't help. Talking with your local UUCP neighbor does. UUNET, are you listening? -- Orlan Cannon oc@vmp.com Video Marketing & Publications, Inc. (800) 627-4551 Oradell, NJ 07649
blarson@blars (12/23/90)
In article <25250@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: >BTW, why doesn't the From: line in your posting have a domain? >"blarson@blars" isn't replyable from outside yours, you know. > - Brian It isn't replyable even on my own machine. blars is not a member of any domain or pseuto-domain, and doesn't yet have a working (to my satisfaction) mailer. I do have plans to fix this and join a real domain (probably .us), but since only one person posts from here, the temporary hack would be whatever magic rn needs to add the reply-to header automaticly. -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
les@chinet.chi.il.us (Leslie Mikesell) (12/23/90)
In article <1990Dec22.014625.22543@Think.COM> barmar@think.com (Barry Margolin) writes: >> The uucp philosophy says that addresses are relative >>to the sender and are only valid in the sender's context. >> To: attmail!somewhere!someone >> Cc: someone@machine.bitnet >>Can anyone's mailer handle a group reply to that? >Only if the bang path is updated whenever the message is forwarded. On the contrary - the recipient's UA can easily construct the path back to the sending machine from the uucp From_ line, but then it can build the destination address only if the headers have been untouched. >A day or so ago, someone (maybe you) mentioned that pure UUCP hosts will >only look at the From_ field. I said that stock /bin/mail only uses the From_ line(s). >The reality is that few hosts are "pure >UUCP". Most hosts using UUCP mail transport also have generic mail user >agents (MH, MUSH, Emacs RMAIL, etc.). Perhaps, if you are talking about the set of machines that participate in usnet. There are lots of machines that just have what someone loads out of the box. Others have commercial alternatives like AT&T's PMX-mailers. >Because of the mix of protocols >being used, most of these will recognize many different mail formats, and >try to deal with them sensibly. If the message looks roughly like RFC-822 >format they'll handle it; the UA rarely needs to parse the address portion >of a header, all it has to do is hand it to the system's MTA. So, even >though the To field in the above example is invalid 822 format there's no >reason for a UA to mind; the UA expects the MTA to deliver messages >containing addresses that it is willing to have returned to it. It is exactly this mix of protocols that causes the problem, and any work-around requires an unfortunate intimacy between the MTA and the UA (and worse, your neighbors MTA). In particular, if the UA wants to handle the relative addressing portion, then the MTA has to leave the To: and Cc: headers alone. If the UA wants the addresses already relative to the local host, then the MTA has to fix them. But, if your MTA "fixes" them for your UA and also anything it passes to your neighbor who doesn't want them fixed, you have created a problem. A reasonable solution would be to adjust the paths so they are relative to the local machine only at final delivery and only if you know the locally used UA's want it that way. I can see a slight advantage in letting the MTA do it in that you may have alternate names for the local machine that the UA doesn't know about which may result in Cc:s to users on the same machine as the recipient having their reply routed back through the sender's host. However the MTA doesn't really know when delivery is complete since the first recipient may forward his copy on to someone else. [...non ascii] >I don't know about UUCP mailers, but RFC-821 mailers are definitely >text-only. Newlines are required to be converted to a standard format so >that mail can be sent between systems with differing newline conventions, >and not all such transformations are perfectly invertible. The uucp mail transport is built on top of a more general file transfer utility and thus will handle anything you throw at it. However, the normal /bin/mail program and the common replacements that parse the addresses and handle forwarding and local delivery are not binary-transparent. Mostly they will lose NULLs due to the way fgets/fputs works. I haven't had any problem with smail 3.1 and I'm using it's bsmtp over uucp on a couple of machines where large lists are active. So far no one has complained about any attachments failing to work when detached so it must be inverting the transformation properly. I don't really expect the attachments to work anywhere but my own uucp links and through the attmail service, but that's where the traffic is. >This is the >reason the FTP protocol has an explicit command to perform binary >transfers. But I don't have a network link and I don't want the users to have to wait for the operation to complete. My traffic tends to be about 100K/day with each of about 60 sites (basically one per state plus a few others) which makes it hard to justify anything but dial-up access. I also don't want to train users in 50 states how to transfer one type of file one way and another type another way and how to tell the difference. >RFC-821 was designed for transfer of text mail; there are other protocols >being developed to solve the more general problem. >You can hammer a nail with a screwdriver, but don't complain to the >screwdriver manufacturer if it's not easy. That portion of the AT&T PMX mailers works just fine. My problem was that I wanted to send mail to users on BITNET and have them reply using their normal reply command instead of having to retype the address as user%afbf05@uunet.uu.net. It turned out to be non-trivial to accomplish that without breaking the extensions provided by the PMX-mail programs, and there are still some unresolved loose ends (but that is a symptom of a more general problem). Les Mikesell les@chinet.chi.il.us
lear@turbo.bio.net (Eliot) (12/24/90)
99.9% of those people who use mailx will not read this message. Those of us who provide services to that (rather large) contingent can either try to force them to change their software (a remedy that many of them may nevver have tried) or allow for their braindamage. On the other hand, there should be no reason why those who have asked to be treated as smart mailers shouldn't be treated just so (I seem to recall the UUNET folks saying that they will treat smart mailers as smart mailers when approached). Mind you this is an argument neither for nor against aggressive rerouting. -- Happy Holidays! Eliot Lear [lear@turbo.bio.net]
chip@tct.uucp (Chip Salzenberg) (12/25/90)
According to les@chinet.chi.il.us (Leslie Mikesell): >In practice, it should be pretty rare that the recipient's response >should go a different route than an error return. Presumed rarity is not an argument against allowing for such a difference. In any case, it is *usually* true here that replies should go a different route, for these reasons: 1. Group replies. 2. Avoiding unreliable sites. 3. Avoiding rabid rerouters (rutgers and bionet). 4. Avoiding Mail Header Mungers From Hell (apple.com). 5. Avoiding pessimal paths generated by sites that aren't using up-to-date maps. For all these reasons, I will always use Reply-To: and From: addresses -- or if they've been munged, signature addresses -- rather than the From_ line. The From_ line is unsuitable anyway, because it is a path to the *sender*, who is not necessarily the user to whom replies should be sent. Thus, to get back to our original subject, it is Evil and Rude to mung an RFC822 address from user@valid.domain into valid.domain!user, because such munging renders impossible the *correct* handling of replies for RFC822-aware but UUCP-only sites. >Using !-notation for the addressing is not at odds with paths routing, >though. In itself, no. But, as you note in an unquoted portion of your article, bang notation is relative, whereas RFC822 notation is absolute. Thus @-to-! translation is a semantic change, not just a syntactic one. Therefore, gratuitous conversion of addresses from absolute to relative is (all together, now): Evil and Rude. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
chip@tct.uucp (Chip Salzenberg) (12/25/90)
Brian Kantor describes UCSD's setup. Two items deserve comment: According to brian@ucsd.Edu (Brian Kantor): >Our rmail has been taught to believe that any bangist address in a From: >line arriving via uucp is likely to be wrong, so it substitutes the From_ >path in place of it. It also does that if there is no domain, the >domain is "uucp", or there is no From: line. This policy is justifiable, in my opinion, for the same reason that the behavior of mailx is not. The From: header is an RFC822 invention, and if you generate one, it should conform to RFC822. >If the mail arriving via uucp contains a From: line like host@dom.ain, >rmail does not alter it at all before passing it to sendmail, and when it >leaves via uucp, we choose the greatest common denominator and issue it >as ucsd!dom.ain!host in the outgoing From: line, and as >"From dom.ain!host date remote from ucsd" in the uucp From line. This policy, however, is totally unjustifiable. As RFC822 gains even wider acceptance among the non-Internet community, more and more UUCP-only sites will be registered with the DNS. Why, oh why, must a site registered with the DNS and complying with RFC822 in every way suffer the slings and arrows of outrageous header rewriting, just because they happen to use UUCP as their mail transport? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
lear@turbo.bio.net (Eliot) (12/26/90)
[Forgive any missed arguments; I'm running on short expires, these days]. chip@tct.uucp (Chip Salzenberg) writes: >In any case, it is *usually* true here that replies >should go a different route, for these reasons: > 1. Group replies. > 2. Avoiding unreliable sites. > 3. Avoiding rabid rerouters (rutgers and bionet). > 4. Avoiding Mail Header Mungers From Hell (apple.com). > 5. Avoiding pessimal paths generated by sites that aren't > using up-to-date maps. (3) and (4) are just plain silly, if they get your mail to where it has to go (and I'll not accept that otherwise is the case unless you show me a failure involving my site). It's your machine, though, and it is always nice to see my name in bits ;-) >Thus, to get back to our original subject, it is Evil and Rude to mung >an RFC822 address from user@valid.domain into valid.domain!user, >because such munging renders impossible the *correct* handling of >replies for RFC822-aware but UUCP-only sites. Well, to use one of your earlier arguments, Chip, just look in the person's .sig or derive the information from the munged from:. Seriously, your mail will always be replyable under the RFC 976 method. This is *NOT* true under your scheme. Most people care about whether or not they will be able to reply to mail, not whether it will go through a path optimizer. To borrow from your hyperbole, it is evil and rude to make mail unreplyable. This isn't to say that you should have to deal with ! paths. You have the following remedies: [1] If your neighbor is doing this to you, either (a) ask to be treated as a Smart UUCP (generally possible) or (b) change neighbors. My understanding is that UUNET can cope with (a), as many sites. [2] If someone way upstream is doing this to you, (a) shortcut and x-late to domains or (b) execute [1] (b). >But, as you note in an unquoted portion of your >article, bang notation is relative, whereas RFC822 notation is >absolute. Thus @-to-! translation is a semantic change, not just a >syntactic one. So what? The real question is whether information is lost. The answer to that question based on RFC 1123 is NO (there used to be one exception). >Therefore, gratuitous conversion of addresses from >absolute to relative is (all together, now): Evil and Rude. See above. It's not gratuitous, and therefore not evil and rude. -- Happy Holidays! Eliot Lear [lear@turbo.bio.net]
les@chinet.chi.il.us (Leslie Mikesell) (12/27/90)
In article <1990Dec22.180814.10207@vmp.com> oc@vmp.com (Orlan Cannon) writes: >The answer is to talk to your UUCP neighbors. Ask what kind of >MTA or MUA they use. Mung the headers accordingly. Don't make >a universal rule of it. No, it's more complicated than this if the neighbor site forwards on to anyone else. While I consider a rewrite from user@domain to domain!user to be a harmless inversion, making things work with real-dumb mailx requires rewriting to site!domain!user (where site is the uucp name of the machine doing the rewriting). This does serious damage to anything that is forwarded on another hop. To make things even more complicated, the forwarding may be done by an alias or forward file on the apparent destination machine. >We've got plenty of universal rules that work just fine. Local >exceptions are *OK*. As long as *you and your neighbor* know >what you're doing. *And anyone your neighbor might forward to.* >Talking about it on the net doesn't help. It might. >Talking with your local UUCP neighbor does. UUNET, are you listening? In fact uunet will give you your choice of munged or unmunged headers but the choice made for the first hop may not be correct for the next. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/27/90)
In article <27763742.4907@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >For all these reasons, I will always use Reply-To: and From: addresses >-- or if they've been munged, signature addresses -- rather than the >From_ line. The From_ line is unsuitable anyway, because it is a path >to the *sender*, who is not necessarily the user to whom replies >should be sent. From the recipient's point of view it is impossible to tell if a header line has been munged or not. Thus your basis for choosing how to reply has a fatal flaw. >Thus, to get back to our original subject, it is Evil and Rude to mung >an RFC822 address from user@valid.domain into valid.domain!user, >because such munging renders impossible the *correct* handling of >replies for RFC822-aware but UUCP-only sites. I disagree here, although prepending a hostname makes any futher intelligent handling impossible. >But, as you note in an unquoted portion of your >article, bang notation is relative, whereas RFC822 notation is >absolute. Thus @-to-! translation is a semantic change, not just a >syntactic one. Therefore, gratuitous conversion of addresses from >absolute to relative is (all together, now): Evil and Rude. That's not quite what I said. I said uucp addresses are relative. The distinction between @ and ! notation is purely syntactic and a sensible MTA will be able to convert user@domain/domain!user (or a!b!c!d to @a,@b:d@c) transparently. The significant difference between relative and absolute addressing is whether the machine where the address was originally written and the machine interpreting it currently share a common naming service. On a uucp machine, that is only known to be true if both happen to be the same machine. As a matter of practicality you may want to interpret the existence of a dot in the machine name to mean that you can pretend that there can only be one such machine that you or some forwarding machine can identify specifically. (And of course internet forwarders that drop .uucp from headers blow away this choice...) Otherwise the only way to get it right is to send it back to the originating machine for interpretation (though it should be safe to chop out any a!b!a hops). This is strictly a UA issue though, since we are talking about taking the header addresses and doing something useful with them. As long as the From_ line contains a path to the sending machine and the other header lines contain more or less what the sender put there, the UA can construct working addresses of any form (!-path relative to sender, domain!user, path!to!smarthost!domain!user, etc.) based on it's best interpretation of what the original address meant at the sending machine. Note that if you deal with attmail you will get header lines with uucp paths that must be interpreted relative to the sending machine so pretending that everyone is one big happy RFC822 family is not possible. Les Mikesell les@chinet.chi.il.us
karl_kleinpaste@cis.ohio-state.edu (12/27/90)
mcr@Latour.Sandelman.OCUnix.On.Ca writes:
I have a question for Karl though (just to add some non-flame content
to my message ;-)
If you are MX'ing for someone
for which you have a UUCP link with them, does it get turned into
some.where.com!user@ohio-state.edu? No right?
So if .UUCP went away, header munging would be a non-issue?
UUCP would still be used as a transport agent though.
Assuming that the uux/rmail interface was deemed to be bad, and one
went the BSMTP route, would we then have lots of problems with
the smart-host'ing being done (or have to do a massive coordination
effort), or would source routes suddenly become popular again?
I've read this note about 5 times in as many days, trying to figure
out what direction you're going or what specific point you're trying
to make. I can't figure it out. That's not an attempt to be rude or
flame; I guess I'm just feeling extraordinarily dense about the
question you're asking -- I can't feel it out.
Anyone for whom I MX, who by definition generates RFC822 headers, gets
their RFC822 headers left intact, no molestation whatever. Anything
that's RFC-compliant is untouched, no matter what the origin: An
RFC-compliant To: line with From: local-dumb-uucp-host!username gets
the To: left alone while the From: may be hacked somewhat.
As far as my configuration is concerned, .uucp has almost entirely
gone away, because it recognizes u@h.uucp just long enough to turn it
into h!u. I don't see that header munging has become a non-issue as a
result.
As for BSMTP, I can contain the same semantic content in uux/rmail as
I can in a BSMTP package. In fact, I do it, for CompuServe -- the
final transport involves a modified BSMTP envelope which is understood
on the CServe side, even though the queueing to CServe was done by
uux/rmail. There is no problem from my perspective with either the
BSMTP or uux/rmail transport interface. I don't see any relationship
to questions of source routes.
Really, I don't know what question/problem you were getting at here.
Am I just yet more dense than usual?
--karloc@vmp.com (Orlan Cannon) (12/27/90)
In article <1990Dec26.160148.19573@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Dec22.180814.10207@vmp.com> oc@vmp.com (Orlan Cannon) writes: > >>The answer is to talk to your UUCP neighbors. Ask what kind of >>MTA or MUA they use. Mung the headers accordingly. Don't make >>a universal rule of it. > >No, it's more complicated than this if the neighbor site forwards on >to anyone else. > >>We've got plenty of universal rules that work just fine. Local >>exceptions are *OK*. As long as *you and your neighbor* know >>what you're doing. > >*And anyone your neighbor might forward to.* You are absolutely right here. There has to be a trickle-down effect. In bringing up these subjects with your UUCP neighbors, you should also be encouraging them to talk to their further downstream neighbors. >>Talking with your local UUCP neighbor does. UUNET, are you listening? > >In fact uunet will give you your choice of munged or unmunged headers >but the choice made for the first hop may not be correct for the next. Not exactly. UUNET will do what you tell them to do, but they will not offer you the choice unless *you* bring it up. Given their prominent position, if they were to distribute information or otherwise aid in educating their customers in what really happens to their mail once it goes out into the world, they might be able to make a real difference. More so than news postings that they may not read. -- Orlan Cannon oc@vmp.com Video Marketing & Publications, Inc. (800) 627-4551 Oradell, NJ 07649
chip@tct.uucp (Chip Salzenberg) (12/28/90)
According to lear@turbo.bio.net (Eliot): >chip@tct.uucp (Chip Salzenberg) writes: >>In any case, it is *usually* true here that replies >>should go a different route, for these reasons: >> 1. Group replies. >> 2. Avoiding unreliable sites. >> 3. Avoiding rabid rerouters (rutgers and bionet). >> 4. Avoiding Mail Header Mungers From Hell (apple.com). >> 5. Avoiding pessimal paths generated by sites that aren't >> using up-to-date maps. > >(3) and (4) are just plain silly, if they get your mail to where it >has to go ... If it makes you feel better, consider (3) and (4) a personal prejudice toward control of the routing of my own site's mail. In any case, the importance of (1), (2) and (5) is undeniable. Thus I still object to the rewriting of RFC822 addresses into bang paths. >>Thus, to get back to our original subject, it is Evil and Rude to mung >>an RFC822 address from user@valid.domain into valid.domain!user, >>because such munging renders impossible the *correct* handling of >>replies for RFC822-aware but UUCP-only sites. > >Seriously, your mail will always be replyable under the RFC 976 >method. This is *NOT* true under your scheme. I do not consider a bang path through unreliable and/or pessimal links to be "replyable." I wouldn't ever use such a path, nor do I appreciate any site's attempt to impose it on me. Yet that is the evident intent of RFC822-to-bang-path header munging. >Most people care about whether or not they will be able to reply to >mail, not whether it will go through a path optimizer. To borrow >from your hyperbole, it is evil and rude to make mail unreplyable. ("Path optimizer"?! That's one of the better euphemisms I've heard for "rabid rerouter." Your idea of optimal and mine may not agree.) The replyability of an RFC822 address cannot be improved by rewriting it into a bang path. Replyability most certainly can be degraded by such a transformation, however, as intermediate sites notice the bang format and (sometimes) prepend their own names, resulting in a bang path which is often incomplete or non-optimal. >The real question is whether information is lost. The answer to that >question based on RFC 1123 is NO (there used to be one exception). I agree that it is usually possible to determine the original RFC822 address given only a bang path a la RFC976. Information loss is not the only issue, however. In the address "bang!path!dom.ain!user", the _added_ information ("bang!path") is the problem, because it is very often an incomplete, pessimal or unreliable route. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
fair@Apple.COM (Erik E. Fair) (12/28/90)
I think it's time I put in my take on this issue. In the referenced article, chip@tct.uucp (Chip Salzenberg) writes: >Brian Kantor describes UCSD's setup. Two items deserve comment: > >>If the mail arriving via uucp contains a From: line like host@dom.ain, >>rmail does not alter it at all before passing it to sendmail, and when it >>leaves via uucp, we choose the greatest common denominator and issue it >>as ucsd!dom.ain!host in the outgoing From: line, and as >>"From dom.ain!host date remote from ucsd" in the uucp From line. > >This policy, however, is totally unjustifiable. As RFC822 gains even >wider acceptance among the non-Internet community, more and more >UUCP-only sites will be registered with the DNS. Why, oh why, must a >site registered with the DNS and complying with RFC822 in every way >suffer the slings and arrows of outrageous header rewriting, just >because they happen to use UUCP as their mail transport? Because they're not using SMTP to do the transport. The UUCP E-mail protocols have different rules and requirements. Because we're in the middle of a protocol conversion, when the vast majority of sites still speak the old protocol (i.e. UUCP mail), and software delivered from the vendors still assumes that standard, rather than the Internet standards. Them's the facts of life. That's why I have apple.com configured to do the same thing as Brian Kantor describes. Like it or lump it. Until UUCP has vanished from the face of the earth, or until we're all using a "bsmtp" command to transfer mail over a UUCP transport instead of "rmail", we all must speak the UUCP protocols in the original when we speak UUCP. As it happens, there is latitude within the original protocols to put domain names in a form that everyone in the UUCP universe can use them (e.g. foo!dom.ain!user). Lucky us. If you and a neighbor agree to do something different across a UUCP connection, that's cool, but don't invoke it with the "rmail" command, because doing that is changing the protocol. You're not supposed to do that. It impedes interoperability. Definitely a "no no." But what I'm really wondering is why Salzenberg and the people who agree with him want all us kind, generous, charitable gateway/forwarder sites to do all the work for him? If you wanna be smart, take RFC976 to its logical conclusion, and convert the dom.ain!user stuff back to user@dom.ain at your site, for your mailers, and enjoy the fruits of that labor. You know your own site names and what a domain name is, so this is allowed, and easy to do. Small matter of software (or configuration, where sendmail is concerned). I did exactly this sort of thing when I was last a postmaster at a pure UUCP site, six years ago. So far as my local users were concerned, it looked like Internet, smelled like Internet, and worked like Internet. They were really happy, and I didn't burden my Internet gateway site's postmaster with my internal E-mail configuration problems. You're wasting your breath (or your keyboard fingers, as the case may be) trying to convince me to do it for you, and in so doing, break E-mail to every old UUCP site that I speak to. So the answer to the original question is: sendmail can and should mung any and every header that it needs to, in order to get the job done right without breaking everyone who is compliant with the appropriate protocols for the network that they're on. The fundamental problem is that there are perhaps 100 people who understand this well enough to get it right, but tens of thousands of sites where it has to be done right, with postmasters who think that because they have read chapter 5 of the "Sendmail Installation and Operation Guide", they are therefore qualified to hack sendmail config files (and after they get it wrong, some of them even have the temerity to argue with those of us who got it right years ago!). You should see what I have to do to get E-mail in and out of AppleLink. Sometimes the transformations are just not reversible, because the destination E-mail system is too brain damaged, and it's so old and entrenched that no one will change it enough to make it work right. I expect that Delphi, CompuServe, MCImail, and GEnie will/do have similar problems in this regard. UUCP E-mail has the opposite problem - it's too simple, too close to the Internet standard, and too malleable, so people believe it can be hacked into being the Internet standard. Sorry folks, 'taint so. If that's what you want, use BSMTP over UUCP instead. Happy New Year, Erik E. Fair apple!fair fair@apple.com Apple Postmaster P.S. Karl, finish the book!
karl_kleinpaste@cis.ohio-state.edu (12/28/90)
chip@tct.uucp writes: >The real question is whether information is lost. The answer to that >question based on RFC 1123 is NO (there used to be one exception). I agree that it is usually possible to determine the original RFC822 address given only a bang path a la RFC976. Information loss is not the only issue, however. In the address "bang!path!dom.ain!user", the _added_ information ("bang!path") is the problem, because it is very often an incomplete, pessimal or unreliable route. So ignore the bang!path portion. My users never even see that part, because of this, in sendmail.cf: S3 ... # # Strip many-hop !-paths to the right-most FQDN; DARR. # R$*.$*!$*@$* $1.$2!$3 lose @-portion R$*!$*.$*!$* $2.$3!$4 strip excess left-hand R$*.$*!$* $3@$1.$2 invert to @-format This converts bang!path!dom.ain!user to user@dom.ain, that is, it undoes an RFC976 conversion. --karl
les@chinet.chi.il.us (Leslie Mikesell) (01/01/91)
In article <277A64CD.4C4B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >In any case, the importance of (1), (2) and (5) is undeniable. Thus I >still object to the rewriting of RFC822 addresses into bang paths. How would you handle the RFC822-legal path!user@domain syntax when handing it to a uux-ed rmail? It is almost certain to mean something different to at least some of the uucp sites in the forwarding path and it will certainly be destroyed by any site that chooses to prepend its uucp name. >I agree that it is usually possible to determine the original RFC822 >address given only a bang path a la RFC976. Information loss is not >the only issue, however. In the address "bang!path!dom.ain!user", the >_added_ information ("bang!path") is the problem, because it is very >often an incomplete, pessimal or unreliable route. Philosophically, I don't like any form of rerouting other than to the specified "next-hop" host, but realistically it is probably better to re-route to the right-most FQDN. That should only fail under a couple of circumstances: (1) the user really wanted the specified routing for testing or avoiding a known problem with the usual routing. (2) the end point has a name with a period in it but can't be found by your routing technique. The second problem could mostly be avoided by forcing the address to be resolved before throwing away the specified route (but this is not possible if a smart-host handles routing but a secondary site is making the decision unless at least a list of top-level domains is kept everywhere). As for the first problem, it would be nice if there were some syntax for specifying that you really want the given route to be used so they could be handled differently than the paths generated by newsreaders, etc.. Les Mikesell les@chinet.chi.il.us
lear@turbo.bio.net (Eliot) (01/01/91)
les@chinet.chi.il.us (Leslie Mikesell) writes: >Philosophically, I don't like any form of rerouting other than to the >specified "next-hop" host, but realistically it is probably better >to re-route to the right-most FQDN. Yes, this should be reasonable, but how you look for an FQDN is very important, as one of the problems you list in your article that I reference is that other things can have dots in their names. In general, I short circuit by looking for recognized top level domains. Basically, I have a class that defines them all. Admittedly, it slows down my mailer just a bitk, and if someone else uses a system that looks and smells like ours but isn't, then a message could conceivably be lost. There is one failure that has occurred in the past when one short circuits, that is really caused by people using forwarders without their knowledge or permission. Example: From: lear@turbo.bio.net (some random internet site) To: 2030@x001.z76.fidonet.org (some fidonet site) If an intermediate site translates 2030@x001.z76.fidonet.org to ucbvax!uunet!rutgers!apple!well!x001.z76.fidonet.org!2030, unless prior arrangements have been made, it is quite likely that the address will be rewritten back to 2030@x001.z76.fidonet.org. A mailer loop. -- Eliot Lear [lear@turbo.bio.net]
chip@tct.uucp (Chip Salzenberg) (01/01/91)
According to les@chinet.chi.il.us (Leslie Mikesell): >In article <27763742.4907@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>For all these reasons, I will always use Reply-To: and From: addresses >>-- or if they've been munged, signature addresses ... > >From the recipient's point of view it is impossible to tell if a header >line has been munged or not. It's just a guess based on experience. I answer the question, "Does that look right?" For "a!b@c", or "a!b!!!", etc. the answer is: "No." >>Thus, to get back to our original subject, it is Evil and Rude to mung >>an RFC822 address from user@valid.domain into valid.domain!user ... > >I disagree here, although prepending a hostname makes any futher >intelligent handling impossible. Such a rewrite cannot improve the address, yet it can easily degrade it, due to the Slings And Arrows Of Outrageous Header Munging (SAAOOHM). If that's not Evil and Rude, I don't know what is. >I said uucp addresses are relative. The distinction between @ and ! >notation is purely syntactic and a sensible MTA will be able to convert >user@domain/domain!user (or a!b!c!d to @a,@b:d@c) transparently. Well, of course translation is possible. That doesn't mean, however, that such a translation has no semantic meaning. Sites that assume that "dom.ain!user" is equivalent to "user@dom.ain" and therefore rewrite the latter into the former cause problems, because that equivalence is not universal. It is common, yes, but not universal. Granted, a site that fits all E-Mail into the Procrustean bed of RFC822 may have to assume that "dom.ain!user" means "user@dom.ain" for mail arriving via UUCP. (For example, Ohio State does so.) I have no objection; handling a UUCP->Internet gateway is an exercise in making best guesses, from all I have read. But on the way out from the Internet onto UUCP, I see no excuse for scrambling the syntax of header addresses into "dom.ain!user" on the assumption that the reworked syntax will be "treated the same." It ain't necessarily so. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
chip@tct.uucp (Chip Salzenberg) (01/01/91)
According to fair@Apple.COM (Erik E. Fair): >In the referenced article, chip@tct.uucp (Chip Salzenberg) writes: >>Why, oh why, must a site registered with the DNS and complying with >>RFC822 in every way suffer the slings and arrows of outrageous header >>rewriting, just because they happen to use UUCP as their mail transport? > >Because they're not using SMTP to do the transport. The UUCP E-mail >protocols have different rules and requirements. I am genuinely puzzled by this fixation on "the UUCP protocol". (EMAIL 101 excerpt, for new readers:) As far as I know, the use of "the UUCP protocol" for E-Mail implies _only_ that mail is transferred using a request of remote execution of the "rmail" command, with the message on standard input and with destination address(es) as command line arguments. Also, the message should begin with a From_ line. These items are often referred to as the "message envelope." Unless I have completely missed the boat, RFC822 does not attempt to describe the envelope (rmail arguments and From_ line -- or, for that matter, SMTP MAIL FROM and RCPT TO strings). So let us leave aside, for now, all consideration of the envelope. Therefore examining only the body of the message, what reason is there to consider a site deficient in implementation of RFC822 based solely on its choice of transport (UUCP rmail)? I see no reason. >But what I'm really wondering is why Salzenberg and the people who >agree with him want all us kind, generous, charitable gateway/forwarder >sites to do all the work for him? This statement genuinely puzzles me. I'm trying to point out that, on balance, header rewriting for mail exchanged by RFC822-compliant sites that happen to use UUCP as a transport is counterproductive, i.e. it causes unnecessary work. I am attempting explain that gateways don't have to turn all those perfectly good domain addresses into bang paths in most cases. I don't understand why such an effort should be considered an attempt at freeloading. >If you wanna be smart, take RFC976 to its logical conclusion, and >convert the dom.ain!user stuff back to user@dom.ain at your site, for >your mailers, and enjoy the fruits of that labor. Well, as I mentioned in an article that you may not have read, I've done exactly that for Elm 2.4dev. But I'm concerned with other sites besides my own. And I have a strong aversion to unnecessary header rewriting in the mail transport. Considering my long effort to save everyone work, and the results, the phrase "tilting at windmills" comes unbidden to mind. <sigh> The way things are going, I may have to hack Smail to put in, for local mail only, some form of address rewriting rules. <double sigh> -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
chip@tct.uucp (Chip Salzenberg) (01/02/91)
According to les@chinet.chi.il.us (Leslie Mikesell): >In article <277A64CD.4C4B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>I still object to the rewriting of RFC822 addresses into bang paths. > >How would you handle the RFC822-legal path!user@domain syntax when >handing it to a uux-ed rmail? For the envelope (rmail argument), make it domain!path!user. For the header, *don't change it*. Remember the basic argument: the From: line is an RFC822 animal. Software that parses From: must therefore do so by the rules of RFC822, or by definition it's broken. >>In the address "bang!path!dom.ain!user", the _added_ information >>("bang!path") is the problem, because it is very often an incomplete, >>pessimal or unreliable route. > >Philosophically, I don't like any form of rerouting other than to the >specified "next-hop" host, but realistically it is probably better >to re-route to the right-most FQDN. That should only fail under >a couple of circumstances: (1) the user really wanted the specified >routing for testing or avoiding a known problem with the usual routing. Agreement 100% here, except that I'm slightly more willing to be guided by my philosophical view and by my desire to avoid problems under the given circumstance (1). I've therefore avoided the use of Rabid Rerouting in our mail transport. The only form of Rabid Rerouting performed at TCT is done in our mail user agent (Elm) and only at explicit user request (the header edit screen has a "domainize" command). I thus avoid the common fallacy that machine X knows better than person Y, which is always false for appropriate values of Y. (The value of X doesn't matter.) My point in requesting the cessation of u@d.m -> d.m!u rewriting is that even my own mild form of Rabid Rerouting wouldn't be needed if only RFC822 headers could get to my site without being mangled. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
tneff@bfmny0.BFM.COM (Tom Neff) (01/02/91)
What I don't like about the rewriting rule where sitea!siteb!sitec!dom.ain!user becomes simply user@dom.ain is the assumption that, on the other side of all those site[abc] nodes, "dom.ain" really means what we think it means! Maybe "sitec" is a gateway to SiberiaNet and 'ti.com' really means Trans-Irkutsk Commune or something! In this sense RFC976 and rabid rerouting could make strange bedfellows. Does a dotted sitename automatically have to conform to the One True DNS or else forfeit legal mention in a UUCP path?
karl_kleinpaste@cis.ohio-state.edu (01/02/91)
chip@tct.uucp writes:
Granted, a site that fits all E-Mail into the Procrustean bed of
RFC822 may have to assume that "dom.ain!user" means "user@dom.ain" for
mail arriving via UUCP. (For example, Ohio State does so.)
Any site running smail 2.5 assumes that dom.ain!user == user@dom.ain.les@chinet.chi.il.us (Leslie Mikesell) (01/03/91)
In article <2781581A.6663@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to les@chinet.chi.il.us (Leslie Mikesell): >>How would you handle the RFC822-legal path!user@domain syntax when >>handing it to a uux-ed rmail? >For the envelope (rmail argument), make it domain!path!user. For the >header, *don't change it*. Remember the basic argument: the From: >line is an RFC822 animal. Software that parses From: must therefore >do so by the rules of RFC822, or by definition it's broken. Well, that may be your basic argument, but there are other views. My personal view is that whatever starts out in the From: line should stay there, with the exception of possibly adding the domain name (if you happen to have one) on messages leaving your domain. However this is already violated by necessity when an internet gateway forwards a message received without a FQDN. Hardly anyone would knowingly use an address like path!user@domain from a uucp site, but they show up in headers all over the place. At&t also has a different view, and you won't find any FQDN's in the headers of messages through attmail, and you must generate group replies by interpreting the From_ line to get the context for the To: and Cc: lines. Too bad that whoever first used the "From:" line didn't patent it (just joking....). >The only form of Rabid Rerouting performed at TCT is done in our mail >user agent (Elm) and only at explicit user request (the header edit >screen has a "domainize" command). I thus avoid the common fallacy >that machine X knows better than person Y, which is always false for >appropriate values of Y. (The value of X doesn't matter.) Of course the real problem is the fact that this is false. The machines should get it right. However, the software designers should have anticipated the problem and allowed an alternative syntax for routes that should or shouldn't be optimized - too late now, I suppose. >My point in requesting the cessation of u@d.m -> d.m!u rewriting is >that even my own mild form of Rabid Rerouting wouldn't be needed if >only RFC822 headers could get to my site without being mangled. And my point in arguing about it is not to favor the rewriting but to point out that the real problem is the later sites who prepend their uucp names and that this is equally likely to happen to RFC822-legal path!user@domain headers with worse results. It is the sites that prepend their uucp names to the headers that cause the damage. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (01/03/91)
In article <277FE143.513F@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>I said uucp addresses are relative. The distinction between @ and ! >>notation is purely syntactic and a sensible MTA will be able to convert >>user@domain/domain!user (or a!b!c!d to @a,@b:d@c) transparently. >Well, of course translation is possible. That doesn't mean, however, >that such a translation has no semantic meaning. If there were any semantic meaning IMHO it should be that in addresses containing a "!", everything to the right of the leftmost "!" should be implicitly quoted (as per the original rmail which just didn't look any farther). Unfortunately, it doesn't necessarily work that way anymore. >But on the way out from the Internet onto UUCP, I see no excuse for >scrambling the syntax of header addresses into "dom.ain!user" on the >assumption that the reworked syntax will be "treated the same." It >ain't necessarily so. The odds are pretty good that the headers were already scrambled as the message went into the SMTP transport if it didn't originate at a site with a FQDN. Les Mikesell les@chinet.chi.il.us
lear@turbo.bio.net (Eliot) (01/03/91)
chip@tct.uucp (Chip Salzenberg) writes: >For the envelope (rmail argument), make it domain!path!user. For the >header, *don't change it*. Remember the basic argument: the From: >line is an RFC822 animal. Software that parses From: must therefore >do so by the rules of RFC822, or by definition it's broken. Actually, I believe one point that has been made abundantly clear in this whole discussion was that just because a header looks and smells like an 822 header, it may not be. -- Eliot Lear [lear@turbo.bio.net]
chip@tct.uucp (Chip Salzenberg) (01/05/91)
According to karl_kleinpaste@cis.ohio-state.edu:
>Any site running smail 2.5 assumes that dom.ain!user == user@dom.ain.
Yup. However, any site running Smail 3.1 or a typical Sendmail
configuration does not make the same assumption. Such sites prepend
"host!" to "dom.ain!user". If these sites considered the two above
addresses to be equivalent, they wouldn't feel the need to modify one
address and not the other.
--
Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
"Please don't send me any more of yer scandalous email, Mr. Salzenberg..."
-- Bruce Beckerjf@ap.co.umist.ac.uk (John Forrest) (01/05/91)
In article <75110378@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >What I don't like about the rewriting rule where > > sitea!siteb!sitec!dom.ain!user > >becomes simply > > user@dom.ain > >is the assumption that, on the other side of all those site[abc] nodes, >"dom.ain" really means what we think it means! Maybe "sitec" is a >gateway to SiberiaNet and 'ti.com' really means Trans-Irkutsk Commune >or something! > >In this sense RFC976 and rabid rerouting could make strange bedfellows. > >Does a dotted sitename automatically have to conform to the One True DNS >or else forfeit legal mention in a UUCP path? The messages under this title are getting more and more bizarre. I write from somewhere where domain names are normal and UUCP the exception. Basically, UUCP names rely on flat naming scheme, and either world wide maps or explicit routes. Domain based schemes rely on knowing where to throw stuff for non-local names - the advantage being that if you see something like inria.fr at least you know what country it is in. Given a name like site.uucp it might as well be on the moon. This is where domain addressing scores, and is why everyone should use it. Of course, the new X400 has through another spanner in the works, but everyone should use it. As far as "ti.com" being in the Soviet Union - "com" is taken a commercial outfit (in the USA or with a states parent), and the rest of us use country abbreviations. Now, as far as being a standard this is very much a de facto one - its in an RFC somewhere, but I'm not aware of their validy under international law. However, people do follow it, under the banner "if you don't it won't work". Of course, there are problems where networks get connections, but these just have to be solved - it is surely no worse than UUCP abbiguities. Back to the original point, when should sendmail munge these headers. As someone has already said, it needs to to ensure that the header is meaningful to the destination host. Faced with a domain, it shouldn't do (in my opinion) if it knows the destination host understands the domain addresses - no reason why it necessarily shouldn't, even with UUCP mail being used. However, if it is not sure, it is better to fix the headers. John Forrest Dept of Computation UMIST.
bruce@balilly.UUCP (Bruce Lilly) (01/14/91)
In article <2784B595.F6A@tct.uucp> chip@tct.uucp (Chip Salzenberg) claims: >According to karl_kleinpaste@cis.ohio-state.edu: >>Any site running smail 2.5 assumes that dom.ain!user == user@dom.ain. > >Yup. However, any site running Smail 3.1 or a typical Sendmail >configuration does not make the same assumption. Such sites prepend >"host!" to "dom.ain!user". Chip, what is your definition of a ``typical Sendmail configuration?'' And on what evidence do you base that definition? -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
chip@tct.uucp (Chip Salzenberg) (01/18/91)
According to bruce@balilly.UUCP (Bruce Lilly): >In article <2784B595.F6A@tct.uucp> chip@tct.uucp (Chip Salzenberg) claims: >>Any site running Smail 3.1 or a typical Sendmail configuration does not >>make the same assumption. Such sites prepend "host!" to "dom.ain!user". > >Chip, what is your definition of a ``typical Sendmail configuration?'' A Sendmail configuration based primarily on a .cf distributed with Sendmail by the vendor. From what I understand, most sites plug-and-play, changing only those things that break their local usage. >And on what evidence do you base that definition? Personal experience and lots of Usenet articles (hearsay). Is it disputed that the transformation from "dom.ain!user" to "localhost!dom.ain!user" is performed by many, if not most, sites that use Sendmail? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "If Usenet exists, then what is its mailing address?" -- me "c/o The Daily Planet, Metropolis." -- Jeff Daiell
bruce@balilly.UUCP (Bruce Lilly) (01/20/91)
In article <279618AF.2EBA@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >Is it disputed that the transformation from "dom.ain!user" to >"localhost!dom.ain!user" is performed by many, if not most, sites >that use Sendmail? I can't speak for most sites which use sendmail, or even for many, but the 3 hosts which I administer don't do that, and based on recent postings, I don't believe that the sites at cis.ohio-state.edu do either. I obviously haven't surveyed all sendmail sites to determine what rewriting rules are in use, but I have only seen the transformation described from a few sites (e.g. rutgers, which also does things to addresses which defy description (although the term rabid has been applied...)). At my sites, "dom.ain!user" is converted to "user@dom.ain" in the headers, and remains "dom.ain!user" in the envelope (for uucp delivery; "user@dom.ain" for delivery via SMTP, as required by RFC's). IMHO that's the only reasonable thing to do*. As for sites where the transformation you describe is made, that's a problem with the *administrator(s)* at those sites, not with sendmail--other software can also be configured to do the same, which I believe is what old versions of rmail did. If you're having problems with some site(s), why not send mail to the postmaster(s) asking that he/they revise their software (which might or might not be sendmail)? *) For feeding mail to downstream uucp sites where rmail understands DNS form and will make any necessary transformations to accomodate the next site downstream, sending the envelope address as "user@dom.ain" would also be reasonable. Lacking specific information about what a downstream site's rmail will accept, and/or what transformations will be performed on envelope addresses, the bangist form has the best chance of success. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
chip@tct.uucp (Chip Salzenberg) (01/24/91)
According to bruce@balilly.UUCP (Bruce Lilly): >In article <279618AF.2EBA@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Is it disputed that the transformation from "dom.ain!user" to >>"localhost!dom.ain!user" is performed by many, if not most, sites >>that use Sendmail? > >... I have only seen the transformation described from a few sites >(e.g. rutgers ...) You can add samsung to that list. All mail I've ever gotten via <samsung!romed!tct> has been munged at samsung. And don't forget Apple.COM and USF.EDU (University of South Florida). >If you're having problems with some site(s), why not send mail to the >postmaster(s) asking that he/they revise their software (which might or >might not be sendmail)? Unfortunately, <postmaster@samsung.com> hasn't answered my mail; and I can never tell who <postmaster@usf.edu> is this week. I don't consider Sendmail evil. I do consider its author to be at least somewhat short-sighted in his making header munging so easy. The header rewriting rules in sendmail.cf are the closest thing I've seen to an E-Mail "attractive nuisance." -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "If Usenet exists, then what is its mailing address?" -- me "c/o The Daily Planet, Metropolis." -- Jeff Daiell