From: T Ziomek <ctz001@email.mot.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] REJECT: Too many recipients to the message
Date: Mon, 1 Jun 2009 16:08:46 -0500 [thread overview]
Message-ID: <20090601210846.GJ8553@email.mot.com> (raw)
In-Reply-To: <20090601205102.A6047832E416@gemini.denx.de>
On Mon, Jun 01, 2009 at 10:51:02PM +0200, Wolfgang Denk wrote:
> Dear T Ziomek,
>
> In message <20090601203258.GG8553@email.mot.com> you wrote:
> >
> > Yes, but how one's MUA / mail client handles them may *not* be identi-
> > cal.
> >
> > Quite a few people configure their MUA to prioritize messages based on
> > whether they are on the To: list, CC:, BCC:, or none of the above (i.e.
> > by list membership).
>
> I read this as a pro for long cc: lists.
Yes.
> > > What is the difference whether you receive one or two identical copies
> > > of a message?
> >
> > It's a hassle and distraction to deal with duplicates.
>
> This however is a clear con, isn't it?
To me, yes. But I'm not active enough on any maillists to be heavily
impacted by it, and I've just dealt with it when it does occur.
I'd assume more active list participants have ways of dealing with that,
but they can answer that better than I.
> > > > How about reconfiguring the list software instead?
> > >
> > > I see no reason for that yet.
I see no reason, at least none articulated as of yet, for the current
configuration.
> > +1 for not restricting the # of addressees absent a reason other than
> > "some of them are often redundant".
>
> We neever before had any such problems. Currently these are caused
> because some messages have 5 (or more) samsung.com addresses listed
> on Cc:; for example, "[PATCH] The omap3 L2 cache enable/disable
> function to omap3 dependent code" has 6 such addresses on Cc:
And what problem does that cause?
> I doubt that this is really necessary.
"Necessary" is in the eye of the beholder here. And IMHO the presump-
tion should be that the sender of an email is addressing it properly.
Absent either (a) clear, significant abuse of emails' recipients or (b)
a measurable and significant impact on the list provider [1], let people
CC who they consider appropriate and let the list server send emails to
whomever it is asked to send emails to.
[1] E.g. exceeding bandwidth quotas, mail delivery being delayed for
hours, etc.
I can understand the hassle you've had manually approving msgs with many
recipients. But the appropriate solution here is to remove the artifi-
cial limit that causes you to be involved in the first place.
> In this specific case, a
> company-internal distribution list would probably be more
> appropriate.
I don't understand what you envision here, or what it would accomplish.
--
A: Because it breaks the logical |
flow of the message. | Email to user 'CTZ001'
| at 'email.mot.com'
Q: Why is top posting frowned upon? |
next prev parent reply other threads:[~2009-06-01 21:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-01 17:58 [U-Boot] REJECT: Too many recipients to the message Wolfgang Denk
2009-06-01 18:39 ` Scott Wood
2009-06-01 18:47 ` Jerry Van Baren
2009-06-01 18:50 ` Scott Wood
2009-06-01 20:01 ` Wolfgang Denk
2009-06-01 20:00 ` Wolfgang Denk
2009-06-01 20:32 ` T Ziomek
2009-06-01 20:51 ` Wolfgang Denk
2009-06-01 21:08 ` T Ziomek [this message]
2009-06-01 22:00 ` Wolfgang Denk
2009-06-01 22:27 ` Scott Wood
2009-06-02 0:09 ` T Ziomek
2009-06-02 6:53 ` Stefan Roese
-- strict thread matches above, loose matches on Subject: below --
2009-06-02 2:52 HeungJun, Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090601210846.GJ8553@email.mot.com \
--to=ctz001@email.mot.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox