🚀 go-pugleaf

In article <4383@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
# Subject: Prompting users for "Cc:" in Mail after message composed is confusing
# Index: ucb 4.3BSD-tahoe
# 
# Description:
# 	If the "askcc" flag is set, "Mail" will, after you've finished
# 	composing the body of a message and typed "." or ^D, prompt you
# 	for a list of carbon-copy recipients.
# 
# 	A lot of users unfamiliar with this behavior will think that if
# 	they type "." at this point, "Mail" will send their message off.
# 	Well, they're right, in a sense, *but* it will also attempt to
# 	send a carbon copy to user ".", and probably fail.
# 
# 	Either "askcc" should ask at a more opportune point, such as
# 	after "Mail" asks for a subject and *before* you compose the
# 	message, or a new option that does that should be provided.
# Repeat-By:
# 	Arrange that "askcc" is set on a lot of accounts used by
# 	people not familiar with this quirk, and watch the bounce
# 	messages pile up in the postmaster's mailbox(es).

I like this feature, and don't consider it a bug.  The mistake is to give
new users intelligent .mailrc files (which would have askcc set).

Where ASKCC (as it currently is) is REAL useful, is when you are typing a
letter (for example, to a customer) and put more into it than you originally
intended, and decide, while composing, that you want to forward a copy of your
response to your customer service department, department head, etc.  Since you
probably did not plan on doing this when you started your article, having it
ask before you start is (usually) insufficient.  (If you did know, you would
probably have invoked mail with the multiple accounts from the command line.)
Having it ask on exit is a REAL useful reminder, asking me "do I want to carbon
this response?" before actually sending the mail.  Of course, without relying
on askcc, I could do a ~h or a ~c, but I shouldn't have to.

I have never seen mail going to the postmaster's mailbox.  Shouldn't an
unknown destination be trapped by the mailer and response be sent back to
the mail user (if I mailed fred@uunet.com, and there is no account
fred@uunet.com, I, the invoker of mail, get mail back.  Root doesn't, or is
this some feature of 4.3 TAHOE?).
-- 
------------------------------------------------------------------------------
Dave Gotwisner					UUCP:  ...!unisoft!peritek!dig
Peritek Corporation				       ...!vsi1!peritek!dig
5550 Redwood Road
Oakland, CA 94619				Phone: 1-415-531-6500

Another advantage of the "Cc:" prompt is it gives you a chance to back out
of an exit (hitting interrupt at that point puts you back into mail).
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com 

>Of course, without relying on askcc, I could do a ~h or a ~c, but I
>shouldn't have to.

I don't particularly care if I have to, and I usually construct the
entire header first, so the way "askcc" works now isn't a win to me
(heck, I don't even turn it on, since I rarely Cc: messages anyway).

That's why one of my suggestions was that options to do it *either* way
be provided, as not *everybody* prefers it the way you do (and no, I'm
not the only one who doesn't, either).

>I have never seen mail going to the postmaster's mailbox.

Well, I have.  Happens all the time here.

>Shouldn't an unknown destination be trapped by the mailer and response
>be sent back to the mail user

Yes, it is, but a copy of the *headers* is also bounced to the
postmaster.

>Root doesn't, or is this some feature of 4.3 TAHOE?).

We're not running 4.3-tahoe, we're running SunOS 4.x, but the behavior
of Berkmail in question is common to a lot of systems (including
S5R2, from whose "mailx" SunOS 3.0 and later's Berkmail is derived, and
also including various flavors of BSD).

In addition, sending a copy of the headers of bounced mail back to
"postmaster" (which happens to be aliased to "root" here) is in most if
not all versions of "sendmail"; note the "P" option in "sendmail.cf", as
in the

	OPPostmaster

line in some "sendmail.cf" files (including ours).

And bouncing a copy back to the user just because they were confused by
"Cc:" is as much of a problem - if not more of a problem - than noting
the bounce to the postmaster, as the user may then think the mail didn't
get to anybody and send it again (the bounced mail that finally provoked
my posting was retried about three times by the user).

in SLIME, the mail environment we use here at CITI, we alias "." to
nobody (which is itself an alias for /dev/null).  end of problem.

	peter

>Another advantage of the "Cc:" prompt is it gives you a chance to
>back out of an exit

In the MH-ish interface, after typing or editing your message it gives
you a "What now?" prompt, letting you abort, edit, defer, or send the
message.  RN's Pnews and Rnmail programs also have a what-now prompt.
I like this style of interface better than Mail's tilde escapes.
--
Felix Lee	flee@cs.psu.edu

In article <1990Nov19.205345.18063@terminator.cc.umich.edu>,
honey@citi.umich.edu (Peter Honeyman) writes:
|> in SLIME, the mail environment we use here at CITI, we alias "." to
|> nobody (which is itself an alias for /dev/null).  end of problem.
|> 
|> 	peter

with apollos, we count on a registry "feature" such that getpwnam(".")
returns the entry for root instead of NULL, so all mail sent to dot
goes to root.  No bounce problems.  Additionally, askcc has the effect
of deletecc in apollo pads, and the bounce problem is thereby avoided.

Just one more example of domain/os superiority over Unix.