haynes@ucscc.UCSC.EDU (99700000) (12/07/90)
Just one of my uucp clients is having a problem. With mail sent to
me from user at that host, the return address is getting rewritten
to somewhere!user@host.uucp He's using some kind of Macintosh
software that is supposed to emulate uucp. Anybody know where
"somewhere" is coming from, and how to get rid of it?
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chroniclerickert@mp.cs.niu.edu (Neil Rickert) (12/07/90)
In article <9812@darkstar.ucsc.edu> haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes) writes: >Just one of my uucp clients is having a problem. With mail sent to >me from user at that host, the return address is getting rewritten >to somewhere!user@host.uucp He's using some kind of Macintosh >software that is supposed to emulate uucp. Anybody know where >"somewhere" is coming from, and how to get rid of it? Most likely the 'somewhere' is coming from your own 'rmail'. Do: strings rmail | grep somewhere as a quick check. 'rmail' is assuming uucp style addressing. It looks at the 'From ' line at the beginning of the incoming message to determine the sender. It expects something like: From host2!host3!user (date and time) remote from host1 or will usually accept: From host1!host2!host3!user (date and time) To determine the sending host, it looks at everything preceeding the first '!', or at the 'remote from' name if present. In the absence of either, it inserts a 'somewhere'. Solutions: Best solution - change the mac software to use 'host!user' or even 'host.UUCP!user' rather than 'user@host.UUCP' Alternate solution - get a different version of 'rmail'. The version distributed with the IDA versions of sendmail, in the subdirectory ida/aux. It will probably have to be run suid root if you don't want the mail to show up as 'From: uucp' or 'From: someuser' where 'someuser' happens to be the person who did a 'uucp' command which initiated the connection. This has the disadvantage that it makes forging sender addresses easier if rmail is publically executable. (I use this version of rmail, and run it suid root. It is executable only by owner (root) or group (daemon). Since 'uuxqt' is sgid daemon, this works for uucp connections, but not for local users directly invoking rmail. (They can probably invoke rmail via uux though, but if they are that clever they already know how to fake out sendmail). Hope this helps. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
kehres@touch.touch.com (Tim Kehres) (12/11/90)
In article <1990Dec6.234758.28937@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: : text regading how rmail looks for bang characters (!) to determine the remote machine name.... > Solutions: > > Best solution - change the mac software to use 'host!user' > or even 'host.UUCP!user' rather than 'user@host.UUCP' I would have to strongly disagree with you here. If a host is passing valid domain style addresses, then rmail should accept them. Forcing old UUCP style addressing on a community simply because of a single broken piece of software in my opinion is not justified. My main disagreement here is not about the two options presented, only the classification of the above as the "best" solution. BTW, the BSD code for rmail (old version) is pretty simple to go through and modify. I have a version of rmail with the changes made, and assuming there are no licensing issues (I believe the source is in several public archives already), I would be happy to send to anyone who needs it. Regards, Tim Kehres
rickert@mp.cs.niu.edu (Neil Rickert) (12/11/90)
In article <198@touch.touch.com> kehres@touch.touch.com (Tim Kehres) writes: >In article <1990Dec6.234758.28937@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >: >text regading how rmail looks for bang characters (!) to determine the remote >machine name.... > >> Solutions: >> >> Best solution - change the mac software to use 'host!user' >> or even 'host.UUCP!user' rather than 'user@host.UUCP' > >I would have to strongly disagree with you here. If a host is passing valid >domain style addresses, then rmail should accept them. Forcing old UUCP style >addressing on a community simply because of a single broken piece of software >in my opinion is not justified. > >My main disagreement here is not about the two options presented, only the >classification of the above as the "best" solution. > While I certainly don't object to changing rmail to accept domain style addresses, and am using such an 'rmail' myself, there are reasons I suggested changing the code on the Mac is the best approach: 1. Changing the mail format on the Mac to conform with UUCP standards will make the MAC address acceptable if it starts talking UUCP to other hosts. 2. Just changing 'rmail' to accept domain style addresses may not be reliable. You may also have to make it suid root, and change it to do setuid(0) internally. (This of course has security implications). The problem is that sendmail tries to prevent a user forging another user's mail. It will only accept a specified 'from' address in one of three conditions: (a) The user invoking sendmail is a 'trusted' user. (Typically root, sendmail, daemon). (b) Sendmail is being run by root. (c) The from address contains a '!'. The last of these options is there specially to accomodate UUCP, because you can not reliably assume that rmail is run by a trusted user. A local user may do a 'uucp' command, which initiates a connection, and collects remote mail. Since many versions of 'sendmail' determine the user from the getlogin() command, the login name of this user will be used to decide if trusted. Usually the answer will be no. All in all, modifying the code of the mac to conform to UUCP standards is likely to be the most reliable and simplest approach. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) (12/12/90)
In article <1990Dec11.040246.11831@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <198@touch.touch.com> kehres@touch.touch.com (Tim Kehres) writes: > 1. Changing the mail format on the Mac to conform with UUCP standards > will make the MAC address acceptable if it starts talking UUCP > to other hosts. Who will either have to deal with the From: headers too (making those hosts more modern), or will not (and munge them) > to do setuid(0) internally. (This of course has security > implications). Why? Mine certainly isn't. My uuxqt is setuid uucp, and my sendmail trusts uucp. What is the problem? uuxqt HAS to be setuid uucp to run. > (a) The user invoking sendmail is a 'trusted' user. (Typically > root, sendmail, daemon). > (b) Sendmail is being run by root. > (c) The from address contains a '!'. > The last of these options is there specially to accomodate UUCP, > because you can not reliably assume that rmail is run by a > trusted user. A local user may do a 'uucp' command, which This should not matter except on very old revisions of the OS. I'm surprised that such old revisions are able to do anything usefull with mail. smail2.5 and sendmail sources are available. > initiates a connection, and collects remote mail. Since many > versions of 'sendmail' determine the user from the getlogin() > command, the login name of this user will be used to decide if Sounds like a broken sendmail. Source is usually available for that (I still haven't gotten source to a Sys V.3 port yet. I know they exist, but they seem rare) -- :!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.
kehres@touch.touch.com (Tim Kehres) (12/12/90)
In article <1990Dec11.040246.11831@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: : > >text regading how rmail looks for bang characters (!) to determine the remote > >machine name.... : : > While I certainly don't object to changing rmail to accept domain style > addresses, and am using such an 'rmail' myself, there are reasons I suggested > changing the code on the Mac is the best approach: > > 1. Changing the mail format on the Mac to conform with UUCP standards > will make the MAC address acceptable if it starts talking UUCP > to other hosts. By supplying a non-broken version of 'rmail', you then have the option of sending either UUCP style bang addresses, or domain addresses. The user has the choice of what to send. You are not force feeding them antiquated addressing types. > 2. Just changing 'rmail' to accept domain style addresses may not be > reliable. You may also have to make it suid root, and change it > to do setuid(0) internally. (This of course has security > implications). I have been running this type of configuration at several sites now for going on two years without any reported problems. There is no need to make the program suid root or anything else (including the referenced call to setuid). All that is being done internally is to not mandate bang style addressing. This of course assumes that you are running sendmail as your router. If this is the case, all you need to do is to take whatever address that is presented to you, and pass it on to sendmail for interpretation and further routing. This type of configuration is especially attractive to sites that are communicating via UUCP to an internet mail forwarder. By specifying a "smart" style of uucp mail agent in the sendmail.cf (one that does not mandate the rewrite of domain style addresses into bang style addresses), it is possible to transparently send and receive mail using domain style addressing without any rewrites taking place. BTW, if you need examples of how to set this up, let me know and I'll provide you with a sample configuration. Several vendors are now supporting this type of configuration, so if you have a recent copy of sendmail from one of the major workstation vendors, you may find examples there as well. > The problem is that sendmail tries to prevent a user forging > another user's mail. It will only accept a specified 'from' > address in one of three conditions: > (a) The user invoking sendmail is a 'trusted' user. (Typically > root, sendmail, daemon). Or uucp or nuucp. When mail come in through UUCP, the user is typicall uucp, or some other id which is associated with uucp. I have yet to see a system where this is a problem. This includes BSD, System V.2, and V.3 systems. > (c) The from address contains a '!'. Perhaps you could show me where there is any reference to this. I have certainly not seen anything like this in any of the rewriting rules that I have come across, likewise never come across any kind of limitations in any of the versions I have either ported or used. The System V machines that I have provided a modified rmail to have never had any problems with sendmail due to the lack of a '!'. (The recent BSD versions of rmail have already fixed this, so they don't need a 'fixed' version). > The last of these options is there specially to accomodate UUCP, > because you can not reliably assume that rmail is run by a > trusted user. A local user may do a 'uucp' command, which > initiates a connection, and collects remote mail. Since many > versions of 'sendmail' determine the user from the getlogin() > command, the login name of this user will be used to decide if > trusted. Usually the answer will be no. I have only come across this as a problem in delivering mail with one implementation of sendmail. All others passed mail correctly, domain names or not. The problem implementation (I would rather not name vendors here), has the problem that, as you say, when uucp is started and remote mail retreived, the UUXQT gets fired off with the uid of the user that initiated the poll, and then sendmail makes the (incorrect) assumption that this is who the mail is from. This particular version however instead of bouncing the mail, does deliver the message, but the UNIX From line gets corrupted in the process. The message From: line however remains intact. Even in this remote case however, there have been no problems in reliable mail delivery. > All in all, modifying the code of the mac to conform to UUCP standards is > likely to be the most reliable and simplest approach. It can most likely be just as reliable as the modification of rmail, but you will still have the problem of not being able to pass valid domain style addresses across your mail interface. Seeing that the UUCP world has been migrating to domain style addressing for the past five or so years, this will continue to be more and more of a problem for anyone that only changes the mac code and expects to be communicating in an internet type of environment. With this in mind, it may be the simplest approach for the system administrator, but probably not for the user. UUCP addressing has always been a pain in the neck for administrators since the addressing is location dependent. This frequently requires significant hand holding by the host administrator with the users in trying to figure out uucp addresses. The domain style addressing has resolved this by letting the system figure out the routing. MUCH simpler for the user. Regards, Tim Kehres
rickert@mp.cs.niu.edu (Neil Rickert) (12/12/90)
In article <1990Dec12.022502.5066@Latour.Sandelman.OCUnix.On.Ca> mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) writes: >In article <1990Dec11.040246.11831@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> to do setuid(0) internally. (This of course has security >> implications). > > Why? Mine certainly isn't. My uuxqt is setuid uucp, and my sendmail >trusts uucp. What is the problem? uuxqt HAS to be setuid uucp to >run. > Running 'setuid uucp' does not mean a whole lot. This means that the effective uid is that of 'uucp'. But 'sendmail' runs 'setuid root' so the only effective uid it sees is that of root. There is no way that 'sendmail' can tell the effective uid of the program invoking it. Therefore it must make any decisions of who invokes based on other information - either the real uid or the login name. >> initiates a connection, and collects remote mail. Since many >> versions of 'sendmail' determine the user from the getlogin() >> command, the login name of this user will be used to decide if > > Sounds like a broken sendmail. Source is usually available for that (I still >haven't gotten source to a Sys V.3 port yet. I know they exist, but >they seem rare) > Finding the identity of the invoker of your program is not as easy as it looks. Try it before you criticize. In the case of an suid program such as 'sendmail' the effective uid is always 0, so no use in determining the invoker. The real uid is not necessarily the right answer either, since several different login names may share the same uid. Since 'sendmail' has to possibly create a return address it has to get it right. The name you logged in as (obtained from getlogin() is reasonably reliable when available. If you use a windowing system, however, you may not be using the login tty, so even this is then unavailable. The versions of 'sendmail' that I have used, up through 5.61 all used getlogin() to determine who invoked the program, and fell back on other means only if that failed. Versions 5.64 and 5.65 also use getlogin(), but check that the uid corresponding to getlogin() corresponds to the realuid, and if not use other means of identification. Here is a test you can make. 1. Login as yourself. 2. Without using a windowing system, script, or other feature that gives a different tty (pty), su to another user. Now send yourself mail. Check the 'From' information. Does it say that the mail came from the name you logged in as, or the one you went to with 'su'? Once again I reiterate - UUCP mail needs to specify the restricted '-f' option to sendmail, and when the loginname invoking UUCP is not always predictable the only reliable approach is to ensure that the from address contains a '!' or that 'rmail' runs with a real uid of 0. In the circumstances of the orinator of this subject line, the surest and simplest approach is to ensure that the Mac originating the mail follows properly the UUCP protocols by using a bang format of address in the 'From ' line. It can use a domain ('@') format on the 'From:' line and the 'To:' line if it wishes, as these cause no problems. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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/14/90)
In article <199@touch.touch.com> kehres@touch.touch.com (Tim Kehres) writes: > >By supplying a non-broken version of 'rmail', you then have the option of >sending either UUCP style bang addresses, or domain addresses. The user has >the choice of what to send. You are not force feeding them antiquated >addressing types. > Actually, 'rmail' has nothing to do with sending mail. It has to do with receiving mail from a uucp connection. >> 2. Just changing 'rmail' to accept domain style addresses may not be >> reliable. You may also have to make it suid root, and change it >> to do setuid(0) internally. (This of course has security >> implications). > >I have been running this type of configuration at several sites now for going >on two years without any reported problems. There is no need to make the Just because there are no reported problems doesn't mean that there are no problems. When the uucp connection is initiated from 'cron' everything will be fine. When initiated from the remote site everything will be fine provided that the login name used by the remote site is in your 'sendmail' list of trusted users. But if a local user does something which causes a UUCP connection (such as a 'uucp' file copy), the mail received from the remote site may have your local user as the sender in the envelope information (the unix 'From ' line). Even with a bad 'From ' line, most user's won't notice the problem, since they only look at the headers. But occasionally mail will disappear into a black hole with no error message. At about the same time your local user who initiated the UUCP connection will receive a bounced mail message for mail which has nothing to do with him. He will probably shrug his shoulders and discard it, and there will be no reported problems. But if your aim is 100% reliability of the mail system you should still be concerned about this even if problems are infrequent. > >> (c) The from address contains a '!'. > >Perhaps you could show me where there is any reference to this. I have >certainly not seen anything like this in any of the rewriting rules that Try the following comments extracted from 'envelope.c' in the sendmail source distribution: ** SETSENDER -- set the person who this message is from ** ** Under certain circumstances allow the user to say who ** s/he is (using -f or -r). These are: ** 1. The user's uid is zero (root). ** 2. The user's login name is in an approved list (typically ** from a network server). ** 3. The address the user is trying to claim has a ** "!" character in it (since #2 doesn't do it for ** us if we are dialing out for UUCP). ** A better check to replace #3 would be if the ** effective uid is "UUCP" -- this would require me ** to rewrite getpwent to "grab" uucp as it went by, ** make getname more nasty, do another passwd file ** scan, or compile the UID of "UUCP" into the code, ** all of which are reprehensible. ** >due to the lack of a '!'. (The recent BSD versions of rmail have already >fixed this, so they don't need a 'fixed' version). The recent BSD versions do not insert a 'somewhere' into the address, but they do nothing to guarantee that 'sendmail' will accept a sender address as authentic if it does not contain a '!'. > >in the process. The message From: line however remains intact. Even in >this remote case however, there have been no problems in reliable mail >delivery. > This subject line originated because of a 'somewhere' showing up in the Unix 'From ' line. If you are only concerned about the 'From:' header, then you presumable do not care about the extraneuous 'somewhere'. >> All in all, modifying the code of the mac to conform to UUCP standards is >> likely to be the most reliable and simplest approach. > >It can most likely be just as reliable as the modification of rmail, but you The appropriate modifications to 'rmail' if complete (and that may require changing the real uid before invoking sendmail) can be completely reliable for uucp mail arriving at your site. It does nothing if the Mac also connects to other sites by UUCP. Changes on the Mac to follow UUCP protocols are the best way to deal with that. >will still have the problem of not being able to pass valid domain style >addresses across your mail interface. Seeing that the UUCP world has been >migrating to domain style addressing for the past five or so years, this and at the present rate will need to continue for many many more years >will continue to be more and more of a problem for anyone that only changes >the mac code and expects to be communicating in an internet type of >environment. Well managed sites with internet addressing which also accept UUCP connections already do a good job of managing both addressing styles and changing between them. Sending internet style envelope addresses via UUCP will never be fully reliable until the UUCP standards are changed. Otherwise you will get those annoying cases of software blindly appending 'uunode!' in front of and internet address to yield 'uunode!user@full.dom.ain' when they really meant 'uunode!full.dom.ain!user'. Most implementations of 'sendmail.cf' will still convert 'user@node.UUCP' into 'node!user' and will convert 'foo.bar.edu!user' to 'user@foo.bar.edu' if the latter is sent out by SMTP. Thus the user of the MAC gains nothing by using 'user@node.UUCP' in place of 'node!user' on the 'From ' line. But by sticking to the bang format it will be much less likely to generate problems when connecting to miscellaneous sites by UUCP. By all means generate the header 'From:' line as 'user@node.UUCP', as this is not involved in transport, and in most cases the worst that can happen is that some site change it to 'node!user'. ------------ This subject line has gone on too long. I don't intend commenting any further if it continues. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
fair@Apple.COM (Erik E. Fair) (12/16/90)
Do NOT under any circumstances change the UUCP mail protocol. If your mail system invokes rmail at the remote end of a UUCP connection, then the first line of standard input (i.e. the letter), MUST be in the form: From addr date remote from uucpname where "uucpname" is your site's UUCP name. Doing anything else is BROKEN, WRONG, and will not work with the vast installed base of UUCP sites around the world. If you want to use domains and RFC822 style addresses instead, use BSMTP (and be prepared to hand source code to your UUCP neighbors for the command you want to invoke on their end), and DON'T invoke it through "rmail". yours for correct interoperation, Erik E. Fair apple!fair fair@apple.com P.S. I am occasionally tempted to register my own UUCP site as "somewhere".
emv@ox.com (Ed Vielmetti) (12/19/90)
In article <47412@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
P.S. I am occasionally tempted to register my own UUCP site as
"somewhere".
You register as "somewhere", I'm signing up for "domain.org", with the
primary site "host.domain.org".
--Ed
emv@ox.comfitz@wang.com (Tom Fitzgerald) (12/30/90)
> In article <47412@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: > P.S. I am occasionally tempted to register my own UUCP site as > "somewhere". emv@ox.com (Ed Vielmetti) writes: > You register as "somewhere", I'm signing up for "domain.org", with the > primary site "host.domain.org". Well, I'm going to cut you both off at the pass and call my site "smart-host", then post lots of chain letters to news.groups as "root@smart-host.UUCP". That oughta cause LOTS of fun. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz