🚀 go-pugleaf

In article <412@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes:
>Our alias file is, as Sun recommends, of the form
>fred:	fred@execu
>joe:	joe@prickleypear
>...etc...

Sounds bogus to me. If fred and joe are real accounts that want to receive
mail on another machine, give them .forward files. If they're not real
accounts and you're setting up forwarding addresses, disregard this
paragraph.

>Is this the right form for smail/sendmail?

The form is fine. Smail knows how to grok Sendmail's alias file format.

>The sendmail.cf from Sun seems to be messed up, at least according to the docs
>I read in one of the Sun manuals.  Supposedly (no, I'm not a guru, not even
>close) the construct for a rhs of $:$>8 should direct more processing to 
>ruleset 8 - but there isn't a S8 in the file...  duh?

If there is no ruleset 8, Sendmail will ignore that rule.

>Final note - is anyone aware of a program called [perhaps] 'ease' for use in
>generating config files?  I tried to look it up, but I don't see it anywhere
>in the indexes I've downloaded.

Ease is a language reminiscent of C that you can use to specify a sendmail.cf
file. The Ease program converts a file written in the Ease language into a
sendmail.cf that can be digested by Sendmail.

And now I wax religious:

I dislike Ease. That puts me into a minority. Learning an entire new language
just to keep one's mailer configured is ridiculous. Sendmail rules are simply
pattern match-and-replaces. The syntax involved is actually easy to learn.
The interactions between rulesets are also straightforward. The difficulty
lies in knowing, in excruciating step-by-step detail, every trifling little
action that must be taken to get Sendmail to deliver a message. Writing
one's configuration in a different format won't change that.

Ease is a waste of time.

If you remain unconvinced and want to try Ease yourself, it's available
from a comp.sources.unix archive. But it's still a waste of time.

Bill, the man from Xanth

[Henize]
# Smail seems to compile pretty well, but I'm running into real problems with
# the sendmail.cf file.  We're a bsd (Sun 4.0.broken) site for a main server,
# and a lot of dec and sun and other machines around besides that.  It
# appears that perhaps the sendmail.cf file is not reading the /etc/hosts
# file at all.
# [...]
# The sendmail.cf from Sun seems to be messed up, at least according to the
# docs I read in one of the Sun manuals.  [...]

I recommend that you try to use the sendmail.cf file that comes with the smail
package rather than back-fitting Sun's config file to use smail for UUCP.  The
Sun config file was a nightmare last time I looked at it (in fairness, the one
in Ultrix is not easy to figure out either), but the one that comes with smail
is sufficient for most purposes, is relatively simple as sendmail config files
go, and makes a great base for later additions.

There are a few gotchas in the config file that smail builds for you, and the
questions it asks you in its build script aren't very clear, but once you get
something that barely works it is only an hour's work to get it to the 99%
point, which is as far as sendmail is ever going to get you anyway.

Moral: throw out the sendmail.cf that came from your CPU vendor and use the
       one that comes with smail.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

[Wisner]
# And now I wax religious:
#
# I dislike Ease. [...]

I agree with most of your conclusions about Ease.  However, I recommend that
anyone interested in understanding sendmail's raw configuration language get
Ease, read all of its documentation, and play with it for a week.  This is
how I finally learned enough about sendmail.cf to write one from scratch.

I might have stayed with Ease if it had made multi-line strings possible; my
"Received:" headers spanned a physical newline and the grammar that came with
Ease at that time would have taken massive hacking to make that possible.
Also, Ease cannot generate the extensions used by IDA.  No fault on the part
of its implementors, since IDA didn't exist when Ease was first conceived.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

[Henize]
>[...]
>The sendmail.cf from Sun seems to be messed up, at least according to the
>docs I read in one of the Sun manuals.  [...]

[Vixie]
>I recommend that you try to use the sendmail.cf file that comes with the smail
>package rather than back-fitting Sun's config file to use smail for UUCP.  The
[...]
>Moral: throw out the sendmail.cf that came from your CPU vendor and use the
>       one that comes with smail.

Even this is not always enough.  It seems that some vendors have changed
sendmail enough that config files for vanilla (i.e. Berkeley) sendmail don't
work with the vendor-supplied version.   Our standard .cf file works fine
with 5.59, but breaks when I give it to either the Ultrix 3.0 sendmail or
the SunOS 4.0 sendmail.  I'm sure the required changes are minor, but I
really have no way of knowing what is different about the vendors' versions.
Rather than try and figure out a black box, we just run 5.59 on everything.

Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and
use the one from ucbarpa.berkeley.edu.

[Busily reverse-engineering the mail11 gateway so we can run Ultrix 3.0...]
--
Keith Moore
UT Computer Science Dept.	Internet/CSnet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus	BITNET: moore@utkvx
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822

In article <697@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore) writes:
>Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and
>use the one from ucbarpa.berkeley.edu.

I'm curious about something.  This config file is used all over berkeley,
as it is at many other sites.  Sometimes, when mail is sent out or when
mail is routed thru said machine, the name-server might fail and your
hostname is not expanded correctly into the fully qualified domain.

The result is the recipient gets mail that says something like:
    From: dheller@cory
As opposed to
    From: dheller@cory.Berkeley.EDU

Many times, I mail to people and they can't reply because "cory" doesn't
make sense (cuz it's not qualified).

The same problem happens when I mail to people at Santa Cruz Operation.
"sco" talks to ucscc.ucsc.edu, so I address the mail:
    To: sco!user@ucscc.ucsc.edu
but when ucsc gets the message, sometimes (when the name server fails to
get info about "ucscc") it rejects the mail with the error:
    ucscc.ucsc.edu: I refuse to talk to myself.

So,  the bottom line is, is it possible to configure a sendmail.cf file
so that if a hostname lookup or a name server lookup fails, it can be
replaced by a known/preset value so that mail can continue to work as
it should.
Dan Heller	<island!argv@sun.com>

In article <7094@xanth.cs.odu.edu> wisner@xanth.cs.odu.edu (Bill Wisner) writes:

>In article <412@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes:

>>Our alias file is, as Sun recommends, of the form
>>fred:	fred@execu
>>joe:	joe@prickleypear
>>...etc...

>Sounds bogus to me. If fred and joe are real accounts that want to receive
>mail on another machine, give them .forward files. If they're not real
>accounts and you're setting up forwarding addresses, disregard this
>paragraph.

As far as I can tell, .forward files don't really fit into a LAN environment.
In my case, I have about four or five YP domains, a corresponding number of
networks, and need to maintain complete interconnectability, for everybody's
convenience. But I can't mount everybody's home directory everywhere, that's
unnecessary and crude - that's what /usr/lib/aliases is for.

When I find .forward files in the LAN - usually as a result of receiving 
mail that looped round and round, before ending up in my mailbox as a problem
report from MAILER-DAEMON - I cat /dev/null into them and chown them to root
and chmod the sucker to 444 and that's that.

Always use /usr/lib/aliases, and concentrate all your network problems into
one place. .forward is an obsolete mechanism from a decade ago.

>Bill, the man from Xanth

What happened to Kent ? You guys merge ?	(-:

-- richard


-- 
 *                     Bismillah hir-Rahman nir-Rahim                         *
 *                                                                            *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *

Richard Childers writes:
> When I find .forward files in the LAN - usually as a result of receiving 
> mail that looped round and round, before ending up in my mailbox as a problem
> report from MAILER-DAEMON - I cat /dev/null into them and chown them to root
> and chmod the sucker to 444 and that's that.

This sounds gratuitously fascist to me. Luckly, it's not hard to remove
such a file:

    helios 7 % ls -l .forward
    -r--r--r--  1 root            0 Jan 18 22:40 .forward
    helios 8 % rm .forward
    rm: override protection 444 for .forward? y
    helios 9 % ls -l .forward
    .forward not found

The advanced reader might want to use "rm -f .forward"

		Craig

[Regarding the selection of newsgroups, I consider it fundamentally wrong
to crosspost to foo.misc as well as foo.x, foo.y, and foo.z.  I've directed
followups to comp.mail.sendmail since that's the most appropriate group.]

In article <412@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes:
> Always use /usr/lib/aliases, and concentrate all your network problems into
> one place. .forward is an obsolete mechanism from a decade ago.

	I'd almost agree with that, except that it would be nice if people
could set up things like vacation on their own (do you, as postmaster,
really want to change /usr/lib/aliases every time somebody goes on vacation
or comes back?)  Of course, the alternative is to have sendmail (or
whatever MTA you use) deal with vacation processing itself.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

>Always use /usr/lib/aliases, and concentrate all your network problems into
>one place. .forward is an obsolete mechanism from a decade ago.

"From a decade ago"? In other words, "sendmail" existed in early 1979?
News to me.  "delivermail" may have existed then, but as I remember it
had "/usr/lib/aliases" but *not* ".forward" files, so "/usr/lib/aliases"
*antedates* ".forward" files.

".forward" is not obsolete; it serves purposes other than to forward
mail from a user's "alternate" accounts to their "primary" account.  For
one thing, it lets you run all your mail through a filter, or a "mail
watcher" such as "vacation"....

(As for mounting everybody's home directory everywhere, while it isn't
necessary, it can sure be *convenient* at times - if I have to work on
several different machines, it's nice to be able to have my environment
travel with me.)

leres@helios.ee.lbl.gov (Craig Leres) writes:

>Richard Childers writes:

>> When I find .forward files in the LAN ... I cat /dev/null into them and
chown them to root and chmod the sucker to 444 and that's that.

>This sounds gratuitously fascist to me. Luckly, it's not hard to remove
>such a file ...

But it is impossible to edit it until it is removed, and provokes the required
dialogue between user and administrator ... which is all I ask.

>The advanced reader might want to use "rm -f .forward"

One presumes that the advanced reader doesn't mangle his .forward ...

Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
by the world. But if you can't trust your users to edit /usr/lib/aliases, then
you probably can't trust them to edit .forward, either.

>		Craig

-- richard


-- 
 *                    -= If it works, it must be a Fluke =-                   *
 *                                                                            *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *

In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes:

>One presumes that the advanced reader doesn't mangle his .forward ...
>
>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
>by the world. But if you can't trust your users to edit /usr/lib/aliases, then
>you probably can't trust them to edit .forward, either.


Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
/usr/lib/aliases.  If someone f*cks up, then we have the simple solution
of asking "who changed the XXX alias to YYY?" and then we can explain to
them the necessity of being more careful in the future.

But if we decided that people were not trustable, then there is a hell of
a difference between mangling your OWN .forward (which only screws up your
own mail) and mangling /usr/lib/aliases (which can steal other peoples' mail,
break vital mailing lists, etc.).  

In short, it may be quite rational to protect users from eachother (by
protecting /usr/lib/aliases), but it IS facism to "protect" people from
themselves.
  Michael I. Bushnell       \     This above all; to thine own self be true
         GIG!                \    And it must follow, as the night the day,
mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
> Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
> /usr/lib/aliases.  If someone f*cks up, then we have the simple solution
> of asking "who changed the XXX alias to YYY?" and then we can explain to
> them the necessity of being more careful in the future.

Thus the cost of providing the flexibility of letting people edit 
/usr/lib/aliases is that, when they screw up, mail screws up -- sometimes
a little, sometimes a lot.  I don't know if I would call this policy 
"enlightened."  I would say it balances things a little more toward 
ease-of-use at the cost of reducing reliability.  Why do they need to
edit /usr/lib/aliaes anyway?  How often does this happen?
-- 
-- uunet!sugar!karl  | "We've been following your progress with considerable 
-- karl@sugar.uu.net |  interest, not to say contempt."  -- Zaphod Beeblebrox IV
-- Usenet BBS (713) 438-5018

>But it is impossible to edit it until it is removed, and provokes the required
>dialogue between user and administrator ... which is all I ask.

Maybe yes, maybe no; they may just get ticked off, as I presume Mr. 
Leres would (and as I probably would, too), and just remove it without
talking to the administrator. 

>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
>by the world. But if you can't trust your users to edit /usr/lib/aliases, then
>you probably can't trust them to edit .forward, either.

Incorrect.  You can screw more people by monkeying with
"/usr/lib/aliases" than you can by editing ".forward"; by editing the
former you can foul up the delivery of mail to people other than
yourself without their consent.

In article <3376@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes:
>In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
>> Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
>> /usr/lib/aliases.  If someone f*cks up, then we have the simple solution
>> of asking "who changed the XXX alias to YYY?" and then we can explain to
>> them the necessity of being more careful in the future.
>
>Thus the cost of providing the flexibility of letting people edit 
>/usr/lib/aliases is that, when they screw up, mail screws up -- sometimes
>a little, sometimes a lot.  I don't know if I would call this policy 
>"enlightened."  I would say it balances things a little more toward 
>ease-of-use at the cost of reducing reliability.  Why do they need to
>edit /usr/lib/aliaes anyway?  How often does this happen?

They (the faculty) maintain several mail aliases for various groups.
They even *create* such aliases relatively frequently.  No one's
*ever* screwed up anyone else's mail.  This makes creating mailing
lists easy for arbitrary users.
  Michael I. Bushnell       \     This above all; to thine own self be true
         GIG!                \    And it must follow, as the night the day,
mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

In article <2253@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
>In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes:
>
>>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
>>by the world. But if you can't trust your users to edit /usr/lib/aliases, then
>>you probably can't trust them to edit .forward, either.
>
>
>Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
>/usr/lib/aliases.  If someone f*cks up, then we have the simple solution
>of asking "who changed the XXX alias to YYY?" and then we can explain to
>them the necessity of being more careful in the future.

Hmmm... you must trust your users very much.
People can not only steal other peoples mail, but can add an alias like
myalias: |/myhome/myprogram

The program /myhome/myprogram will be executed with the uid sendmail uses
for untrusted mailers. If it is daemon (it is on my systems) the user
could then 'do some things I will not disclose here' and become root
in a matter of minutes.

At that point he can do more damage to your system than you can repair
in the time saved by letting your users edit /usr/lib/aliases.

>In short, it may be quite rational to protect users from eachother (by
>protecting /usr/lib/aliases), but it IS facism to "protect" people from
>themselves.

Agreed

>  Michael I. Bushnell       \     This above all; to thine own self be true
>         GIG!                \    And it must follow, as the night the day,
>mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
>  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!


____________________________________________________________________________
Casper H.S. Dik
University of Amsterdam     |		      dik@uva.uucp
The Netherlands             |                 ...!uunet!mcvax!uva!dik

In article <608@uva.UUCP> dik@uva.UUCP (Casper H.S. Dik) writes:

>Hmmm... you must trust your users very much.
>People can not only steal other peoples mail, but can add an alias like
>myalias: |/myhome/myprogram

Our goal for security is to prevent users from doing accidental
damage.  We can restore the system from tape in a matter of
hours--with little loss of data.  The offending person is easily
determined, and we can easily use administrative means to can them.  

>The program /myhome/myprogram will be executed with the uid sendmail uses
>for untrusted mailers. If it is daemon (it is on my systems) the user
>could then 'do some things I will not disclose here' and become root
>in a matter of minutes.

In the interests of letting people know what we mean, you could, for
example, modify the atq and have jobs executed as root.  The atq is,
on most systems, owned by daemon, so daemon can modify it and have
jobs run under any uid.

>At that point he can do more damage to your system than you can repair
>in the time saved by letting your users edit /usr/lib/aliases.

As I said, not too much damage.  We don't worry.  Administrative
control is far better than online security.

  Michael I. Bushnell       \     This above all; to thine own self be true
         GIG!                \    And it must follow, as the night the day,
mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

dik@uva.UUCP (Casper H.S. Dik) writes:

>mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:

>>In short, it may be quite rational to protect users from eachother (by
>>protecting /usr/lib/aliases), but it IS facism to "protect" people from
>>themselves.

>Agreed

I beg to disagree, gentlebeings. I am not intent on 'protecting users from
each other' when I forbid ~{user}/.forward files ... I am protecting myself.

It's not a matter of facism. It's a matter of functionality. I have a mandate,
as it were, to maintain the mail subsystem. I also have an unofficial mandate
to order my tasks in such a way as to avoid wasting my time. Reading mail to
'root' from 'MAILER-DAEMON', time after time, is a waste of my time. I know
what the problem is, I know there is no way I'll ever be able to educate the
entire user community, there's always someone browsing the manual - and that,
in itself, is a blessing of sorts, since they aren't asking me - so I created
a solution, the simplest, cheapest solution I could think of. It works.

The meter for determining if the mailer subsystem works, is whether you get
any mail from users or MAILER-DAEMON complaining. That's the only meter that
really counts. I'm not interfering in anyone's productivity, I'm keeping them
from impinging on mine.

You may call it administrative fascism ... but I think of it as facilitating
things, overall ... maintaining functionality, at the cost of an occasional
damaged ego, perhaps, but maintaining functionality. One person objects, but
they are inevitably a minority. Is this fascism ?

>>  Michael I. Bushnell       \     This above all; to thine own self be true
>>         GIG!                \    And it must follow, as the night the day,
>>mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
>>  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

-- richard

-- 
 *       "Do not look at my outward shape, but take what is in my hand."      *
 *                            -- Jalaludin Rumi, 1107-1173                    *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *