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 19:09:22 -0500 [thread overview]
Message-ID: <20090602000922.GK8553@email.mot.com> (raw)
In-Reply-To: <20090601220021.3F722832E416@gemini.denx.de>
On Tue, Jun 02, 2009 at 12:00:21AM +0200, Wolfgang Denk wrote:
> Dear T Ziomek,
>
> In message <20090601210846.GJ8553@email.mot.com> you wrote:
> >
> > > > > > 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.
>
> The current configurations is (1) the default one,
Unless there's a good reason it's the default, I wouldn't defer to that
in the presence of good arguments otherwise.
>and (2) pretty
> useful to detect list abuse that has not been cought yet by other
> means.
What sort(s) of abuse has configuration this helped catch?
> > > 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?
>
> Such messages need manual moderation which (1) delays the messages and
> (2) causes additional work to the list moderator (me).
But that's a problem caused by the list server's config, not inherently
by the # of CCs.
> > > 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 take this example back; as Scott reminds us the CCs don't affect the
list server (except for a few more bytes in the headers of a message it
relays). In which case I have even more trouble seeing the harm in re-
moving the list server's [apparently arbitrary and unsubstantiated] CC
limit. Or at least changing it to a much higher number.
> Messages get delayed, and they exceed my patience quota ;-)
Again, not inherently because of having "too many" CCs.
Raise/remove the limit, and your immediate issue is resolved. What's
not to like?
Tom
--
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-02 0:09 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
2009-06-01 22:00 ` Wolfgang Denk
2009-06-01 22:27 ` Scott Wood
2009-06-02 0:09 ` T Ziomek [this message]
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=20090602000922.GK8553@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.