gregc@cgl.ucsf.edu (Greg Couch) (07/12/89)
A bit of background: we share a password file amoung several 4.3 systems
and restrict access to a particular system by having login fail if the
user doesn't have a home directory on that system. Thus we don't want
users to get mail on machines they can't access.
Enclosed is a small enhancement to reject mail to users that don't have
home directories. Depending on how your site manages accounts, you might
want to disable mail to users with non-standard shells or to users whose
password entry is "*" or somesuch.
This patch works for sendmail versions 5.59 and 5.61.
- Greg Couch
gregc@cgl.ucsf.edu
postmaster@cgl.ucsf.edu
------
sendmail/src/recipient.c:
------
RCS file: RCS/recipient.c,v
retrieving revision 1.1
diff -c -r1.1 recipient.c
*** /tmp/,RCSt1024920 Tue Jul 11 15:09:13 1989
--- recipient.c Tue Jul 11 14:52:40 1989
***************
*** 303,309
/* warning -- finduser may trash buf */
pw = finduser(buf);
! if (pw == NULL)
{
a->q_flags |= QBADADDR;
giveresponse(EX_NOUSER, m, CurEnv);
--- 303,309 -----
/* warning -- finduser may trash buf */
pw = finduser(buf);
! if (pw == NULL || !safefile(pw->pw_dir, pw->pw_uid, S_IEXEC))
{
a->q_flags |= QBADADDR;
giveresponse(EX_NOUSER, m, CurEnv);roy@phri.UUCP (Roy Smith) (07/12/89)
In article <11680@cgl.ucsf.EDU> gregc@cgl.ucsf.edu (Greg Couch) writes: > we share a password file amoung several 4.3 systems and restrict access > to a particular system by having login fail if the user doesn't have a > home directory on that system. Thus we don't want users to get mail on > machines they can't access. Enclosed is a small enhancement to reject > mail to users that don't have home directories. Yuck! This really seems rather needless. Why not just share /usr/lib/aliases files as well? Have each person have an alias pointing to the machine where their home directory is. Not only is that much simplier than hacking sendmail, but it also allows people to send mail to somebody without having to know which machine they are on. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
gregc@cgl.ucsf.edu (Greg Couch) (07/14/89)
I should have given a bit more background. We sort of share the alias file among the various hosts by routing all mail that only has a user in the address through the mail gateway for our lab. All outgoing mail appears to be from the mail gateway so we're free to change any of the other host names at will. Mail to a particular host will be delivered on that host so a local user may pick which host he wants to read mail on. Consequently, with sharing of the password file and the not allowing logging in to hosts that the user doesn't have a home directory on, mail needed to be disabled to accounts that don't have home directories. True sharing of the alias file would solve the above problem, except: When we turn off an account, we don't remove a user from the password file (just disable the password, change the shell to /noshell, and rm -rf the account). The local mailer can't be changed to reject mail to disabled accounts because sendmail thinks that all local mailer errors are temporary. Thus sendmail had to be changed to not deliver the mail in the first place. This has the nice side effects of having the SMTP VRFY command return "User Unknown" for disabled accounts and of causing errors in mailing lists that include that user. If you have the second problem but not the first, you could alter my change from checking if the home directory exists to checking if the shell is /noshell (or whatever your local convention is). Further followups have been redirected to comp.mail.sendmail. - Greg Couch gregc@cgl.ucsf.edu gregc@ucsfcgl.bitnet
rcodi@chudich.co.rmit.oz (Ian Donaldson) (07/14/89)
From article <11680@cgl.ucsf.EDU>, by gregc@cgl.ucsf.edu (Greg Couch): > A bit of background: we share a password file amoung several 4.3 systems > and restrict access to a particular system by having login fail if the > user doesn't have a home directory on that system. Thus we don't want > users to get mail on machines they can't access. > > Enclosed is a small enhancement to reject mail to users that don't have > home directories. Depending on how your site manages accounts, you might > want to disable mail to users with non-standard shells or to users whose > password entry is "*" or somesuch. A related problem is when one of the disks containing the users' home directory drops dead and the machine is brought up without that disk online. The ".forward" files that users' have aren't accessable anymore, so the mail ends up in /usr/spool/mail. When the disk then come up, and the home directories return, the ".forward" files do also, and people wonder (on other machines) where their mail went to... This fix would cause such mail to bounce, which at least tells somebody (the sender) what has happened to it. What I think would be preferable in this case is for the mail to be held-over (in /usr/spool/mqueue) until the home directory of the recipient can be accessed, so that a ".forward" file can be searched for. I think that the fix in this article should involve something along the lines of... if /usr/spool/mail/user is mode 000 then no mail should be receiveable for that user on this machine, and so bounce the mail. This makes it easy to tune... just create a mail box file, mode 000 for such users! Put some crap in it if you have scripts that clean out empty mail boxes upon reboot... If the user had a mailbox already there, then the user could even turn off/on the feature himself via chmod(1) (since he owns the mailbox file) The mod would probably go in BSD /bin/mail, to check for mode 000 files. Ian D