Subject: Rmail queues everything?

From: [email-masked]

Why does the current source for rmail queue everything it sends through
sendmail? i.e. it's passing -odq to sendmail which makes it queue
incoming mail automatically.

This has been around for a while (I can find it in original net2 source).
but I finally got tired out of it and went looking. Is there any real
reason to do this? If the mail needs to be queued, then the site
sendmail.cf should make that decision since it's easily modified. Most
people's uucp mailer definition will have the "e" option enabled if
they need mailed queued first anyways. But, since a fair amount of
incoming uucp mail is locally bound anyways it should get delivered
if at all possible.

I personally am quite capable of changing my source here obviosuly (and
did so), but since this isn't documented anywhere it's slightly wierd
behavior. The rmail I've used on sunos doesn't do this, but that doesn't
mean a whole lot either :-)

Just looking for other people's thoughts on this.

James

---

From: DNS Master <[email-masked]>

#define AUTHOR "[email-masked] ([email-masked])"
/*
 * Why does the current source for rmail queue everything it sends through
 * sendmail? i.e. it's passing -odq to sendmail which makes it queue
 * incoming mail automatically.

[ ... ]

 * Just looking for other people's thoughts on this.
 * 

Are you saying that rmail should not queue everything, or are you
saying that rmail should not call sendmail?

If the latter, I have news:  SunOS rmail does call /usr/lib/sendmail.
It looks like it calls
	/usr/lib/sendmail -oMs{sender} -oMr{recipient}

(this from doing a "strings").

 * James
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 */

#undef AUTHOR	/* "[email-masked] ([email-masked])" */

--
 _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so)
/ ___\ _ \ __\ V / \  / /__ \| | __/WHAT: UNIX System Mangler...er, Admin
\ \| |   < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc.  3 Harbor Dr.
 \___|_|\_\__\|_|  \/\/ \__/___/_|  Sausalito, CA 94965 (415) 332-2344 x4219
	see also: [email-masked]

---

From: [email-masked]

>(this from doing a "strings").

This it obviously has to do. What I was questioning was the -odq flag
it's passing to sendmail. The job to queue or not should be left to sendmail
and to sendmail.cf. There's few other times I could see something needing
to over ride this, and this certainly doesn't seem like one.

James

---

From: "Mark P. Gooderum" <[email-masked]>

According to [email-masked]:
> reason to do this?
> ...

I can think of one.  A non-queueing sendmail will attempt delivery
itself.  This can hang if DNS will hang (for instance you dial up
part time to the net only, and other times, there is no root DNS 
server reachable).  This can be bad for something running out of
uucp.  Also, on larger systems, an rmail to many recipients can take
time, esp. if the host is forwarding to others, and what if one of 
those is down, etc, etc.

I ran into this, I just had my cron job run sendmail -q after UUCP
was finished (I ran uucico in the foreground, then ran sendmail -q).
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark P. Gooderum			   USSnail:  Good Creations
Senior Consultant - Operating Systems Group	     3029 Blackstone Ave. So.
  "Working hard to be hardly working..."	     St. Louis Park, MN 55416
EMail:	     [email-masked]		   Voice:    (612) 922-3953
Interactive: [email-masked]	   Fax:	     (612) 922-2676
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: [email-masked]

>time, esp. if the host is forwarding to others, and what if one of 

My point here was, is this is a site specific configuration issue. Leaf
uucp sites only get mail for themselves generally. Queuing in that case
makes no sense. The choice to queue or not queue incoming uucp mail
should be something left up to the machine admin in a configuration
file, not compiled into rmail. If you want outgoing mail to always queue
just set e on the Mailer definitions. However if I don't want it to
queue I have no choice but to go get the rmail source and modify it (once
I figure out why it's happening.)

>was finished (I ran uucico in the foreground, then ran sendmail -q).

It's what I was doing, but there's no point in even having to do this if
the option was left up to sendmail.cf like it should be. At the worst case
the rmail man page needs to be updated to note the fact it passes these
options to sendmail.

James

---

From: DNS Master <[email-masked]>

[ sorry about the bandwidth, but I couldn't pass this one up. ]

#include <std/protocol.h>
#define MESSAGE_TONE (F_SARCASM|F_HUMOUR)

A [insert large conglomerate] rep would say, "Look at it this way:  If you
configure your high water load average in sendmail.cf properly, sendmail
will eventually stop trying to deliver the mail presented by rmail and just
queue the messages anyway..."

#undef MESSAGE_TONE

Yes, something like that should be run-time configurable, and probably
in an rmail.conf file or some such.

A side note:  With all the .conf files (inetd.conf, syslog.conf,
newsyslog.conf) should we make an /etc/conf directory in which we stuff
all the config files, or is this just opening a can of pointers to worms?

#define AUTHOR "[email-masked] ("John F. Woods")"

/*
 * I was going to offer my own opinion about whether uucp mail should be
 * delivered immediately, but it struck me that since it was going to be
 * the third different opinion so far, it really underlined the central
 * message of the original piece of mail:  this ought to be _configurable_,
 * without having to edit source code.  I guess that implies that the
 * queue/no-queue decision should be left to sendmail; probably rmail should
 * use -odi to ensure it waits for sendmail to finish (so you don't get dozens
 * of sendmails all competing for a chance to save system time by queueing their
 * messages :-).  At any rate, I think the best approach is to make sure the
 * configuration can be done simply (well, as simple as sendmail gets).
 */

#undef AUTHOR	/* "[email-masked] ("John F. Woods")" */

---

From: Martin Husemann <[email-masked]>

> If rmail would call sendmail without specifying a delivery mode, you'd
> have several parallel sendmail processes delivering mail after a normal UUCP
> connection (due to the store-and-forward nature of UUCP). Delivering
> queue-only reduces the system load, since only one sendmail process
> (the daemon) handles the mail.

Sendmail is very expensive. I used to use (and do it on most boxes still)
Smail-3.1.28 and now turned to a real native NetBSD 1.0_Beta on this
system for the first time. I don't notice any exspacialy high load after
uucp calls on the smail systems, but I get my mail instantly (Smail works
in foreground for local deliveries and may go to background mode if configured
for SMTP or other transports).

While I personaly prefer the non-queued rmail operation I see this become
holy war. What I realy would like is a way to keep Sendmail from beeing
build at all! While it probably is the most frequently used MTA it's not
the only choice and I think doesn't belong into a base system. I don't
mind getting it for free (otherwise I never would have realy tried it),
but it prevents me from installing another MTA and keeping current.

A simple environment variable NO_SENDMAIL (ala NO_MAN) would be great!

Martin

P.S.: Or somebody could point me to sendmail m4 macro packages to handle
      (a) compressed batched smtp and (b) alternating DNS/smart-host routing
      depending on the state of a PPP link; I might give up smail then ;-}

-- 
"If you lie to your compiler, it will get its revenge."    -- Henry Spencer