Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.sendmail Subject: Re: problem with uucp-originated mail Message-ID: <1990Dec13.161428.1822@mp.cs.niu.edu> Date: 13 Dec 90 16:14:28 GMT References: <198@touch.touch.com> <1990Dec11.040246.11831@mp.cs.niu.edu> <199@touch.touch.com> Organization: Northern Illinois University Lines: 126 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 Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940