* [U-Boot] REJECT: Too many recipients to the message
@ 2009-06-01 17:58 Wolfgang Denk
2009-06-01 18:39 ` Scott Wood
0 siblings, 1 reply; 14+ messages in thread
From: Wolfgang Denk @ 2009-06-01 17:58 UTC (permalink / raw)
To: u-boot
Hi,
there is an increasing number of postings with loooooong lists of
recipients (10 addresses and more); usually several of these are
regular and active users of this mailing list so this is actually
redundant; for the remaining addresses question is if these people
really need to be informed, and if so, if they should rather
subscribe to the list (or if a company-internal mailing list address
should be used instead).
So far, I have manually ACKed all postings that were helt by the
mailing list software because of too many recipients. From now on, I
will not do this any more, but rather reject those messages.
Please restrict yourself - 10 or more explicit reciepients are not
really needed.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Success covers a multitude of blunders." - George Bernard Shaw
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
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 20:00 ` Wolfgang Denk
0 siblings, 2 replies; 14+ messages in thread
From: Scott Wood @ 2009-06-01 18:39 UTC (permalink / raw)
To: u-boot
Wolfgang Denk wrote:
> there is an increasing number of postings with loooooong lists of
> recipients (10 addresses and more); usually several of these are
> regular and active users of this mailing list so this is actually
> redundant;
It is not redundant -- including a person in the CC list brings the mail
to their attention faster (and with less chances of missing it) than if
they have to pick it out of the list.
Though it seems that sometimes I don't get a copy delivered directly to
me, but only the list e-mail -- even though I'm in the CC. I think this
happens when the mail is sent from someone @denx.de, so the server
discards the duplicate, defeating the whole point of CCing a particular
person.
> for the remaining addresses question is if these people
> really need to be informed, and if so, if they should rather
> subscribe to the list (or if a company-internal mailing list address
> should be used instead).
>
> So far, I have manually ACKed all postings that were helt by the
> mailing list software because of too many recipients. From now on, I
> will not do this any more, but rather reject those messages.
How about reconfiguring the list software instead?
-Scott
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
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:00 ` Wolfgang Denk
1 sibling, 1 reply; 14+ messages in thread
From: Jerry Van Baren @ 2009-06-01 18:47 UTC (permalink / raw)
To: u-boot
Scott Wood wrote:
> Wolfgang Denk wrote:
>> there is an increasing number of postings with loooooong lists of
>> recipients (10 addresses and more); usually several of these are
>> regular and active users of this mailing list so this is actually
>> redundant;
>
> It is not redundant -- including a person in the CC list brings the mail
> to their attention faster (and with less chances of missing it) than if
> they have to pick it out of the list.
>
> Though it seems that sometimes I don't get a copy delivered directly to
> me, but only the list e-mail -- even though I'm in the CC. I think this
> happens when the mail is sent from someone @denx.de, so the server
> discards the duplicate, defeating the whole point of CCing a particular
> person.
That is actually a MailMan feature. If you go to your personal
configuration page, you will find the last option to be...
------------------------------------------------------------------------
Avoid duplicate copies of messages?
When you are listed explicitly in the To: or Cc: headers of a list
message, you can opt to not receive another copy from the mailing list.
Select Yes to avoid receiving copies from the mailing list; select No to
receive copies.
------------------------------------------------------------------------
[snip]
gvb
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 18:47 ` Jerry Van Baren
@ 2009-06-01 18:50 ` Scott Wood
2009-06-01 20:01 ` Wolfgang Denk
0 siblings, 1 reply; 14+ messages in thread
From: Scott Wood @ 2009-06-01 18:50 UTC (permalink / raw)
To: u-boot
Jerry Van Baren wrote:
> That is actually a MailMan feature. If you go to your personal
> configuration page, you will find the last option to be...
>
> ------------------------------------------------------------------------
> Avoid duplicate copies of messages?
>
> When you are listed explicitly in the To: or Cc: headers of a list
> message, you can opt to not receive another copy from the mailing list.
> Select Yes to avoid receiving copies from the mailing list; select No to
> receive copies.
> ------------------------------------------------------------------------
I already have that set to "no". It's not the list e-mail that isn't
making it, but the direct CC e-mail. It only happens some of the time.
-Scott
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 18:39 ` Scott Wood
2009-06-01 18:47 ` Jerry Van Baren
@ 2009-06-01 20:00 ` Wolfgang Denk
2009-06-01 20:32 ` T Ziomek
2009-06-02 6:53 ` Stefan Roese
1 sibling, 2 replies; 14+ messages in thread
From: Wolfgang Denk @ 2009-06-01 20:00 UTC (permalink / raw)
To: u-boot
Dear Scott Wood,
In message <4A242071.1010806@freescale.com> you wrote:
>
> > there is an increasing number of postings with loooooong lists of
> > recipients (10 addresses and more); usually several of these are
> > regular and active users of this mailing list so this is actually
> > redundant;
>
> It is not redundant -- including a person in the CC list brings the mail
> to their attention faster (and with less chances of missing it) than if
> they have to pick it out of the list.
An email message is a message is a message, isn't it? The message on
the list and the Cc: are identical, aren't they?
What is the difference whether you receive one or two identical copies
of a message?
> How about reconfiguring the list software instead?
I see no reason for that yet.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a train station is a place where a train stops,
then what's a workstation?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 18:50 ` Scott Wood
@ 2009-06-01 20:01 ` Wolfgang Denk
0 siblings, 0 replies; 14+ messages in thread
From: Wolfgang Denk @ 2009-06-01 20:01 UTC (permalink / raw)
To: u-boot
Dear Scott Wood,
In message <4A242313.3060307@freescale.com> you wrote:
>
> I already have that set to "no". It's not the list e-mail that isn't
> making it, but the direct CC e-mail. It only happens some of the time.
To the best of my knowledge both messages get sent, but it seems some
servers drop them on the receiving side, if the message ID is already
known.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A student of probability soon realizes that by its nature the
billion-to-one chance crops up nine times out of ten, and that the
greatest odds boil down to a double-sided statement: it will happen,
or it will not. - Terry Pratchett, _The Dark Side of the Sun_
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 20:00 ` Wolfgang Denk
@ 2009-06-01 20:32 ` T Ziomek
2009-06-01 20:51 ` Wolfgang Denk
2009-06-02 6:53 ` Stefan Roese
1 sibling, 1 reply; 14+ messages in thread
From: T Ziomek @ 2009-06-01 20:32 UTC (permalink / raw)
To: u-boot
On Mon, Jun 01, 2009 at 10:00:12PM +0200, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <4A242071.1010806@freescale.com> you wrote:
> >
> > > there is an increasing number of postings with loooooong lists of
> > > recipients (10 addresses and more); usually several of these are
> > > regular and active users of this mailing list so this is actually
> > > redundant;
> >
> > It is not redundant -- including a person in the CC list brings the mail
> > to their attention faster (and with less chances of missing it) than if
> > they have to pick it out of the list.
>
> An email message is a message is a message, isn't it? The message on
> the list and the Cc: are identical, aren't they?
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).
> 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.
> > How about reconfiguring the list software instead?
>
> I see no reason for that yet.
+1 for not restricting the # of addressees absent a reason other than
"some of them are often redundant".
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? |
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 20:32 ` T Ziomek
@ 2009-06-01 20:51 ` Wolfgang Denk
2009-06-01 21:08 ` T Ziomek
0 siblings, 1 reply; 14+ messages in thread
From: Wolfgang Denk @ 2009-06-01 20:51 UTC (permalink / raw)
To: u-boot
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.
> > 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?
> > > How about reconfiguring the list software instead?
> >
> > I see no reason for that yet.
>
> +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:
I doubt that this is really necessary. In this specific case, a
company-internal distribution list would probably be more
appropriate.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Vulcan can no sooner be disloyal than he can exist without
breathing.
-- Kirk, "The Menagerie", stardate 3012.4
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 20:51 ` Wolfgang Denk
@ 2009-06-01 21:08 ` T Ziomek
2009-06-01 22:00 ` Wolfgang Denk
0 siblings, 1 reply; 14+ messages in thread
From: T Ziomek @ 2009-06-01 21:08 UTC (permalink / raw)
To: u-boot
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? |
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
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
0 siblings, 2 replies; 14+ messages in thread
From: Wolfgang Denk @ 2009-06-01 22:00 UTC (permalink / raw)
To: u-boot
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, and (2) pretty
useful to detect list abuse that has not been cought yet by other
means.
> > 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).
> > 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.
Messages get delayed, and they exceed my patience quota ;-)
> > 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.
They could Cc: u-boot-addicts at foo.com (i. e. just one address) and
distribute this internally to anybody who might be interested.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I used to be indecisive, now I'm not sure.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 22:00 ` Wolfgang Denk
@ 2009-06-01 22:27 ` Scott Wood
2009-06-02 0:09 ` T Ziomek
1 sibling, 0 replies; 14+ messages in thread
From: Scott Wood @ 2009-06-01 22:27 UTC (permalink / raw)
To: u-boot
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, and (2) pretty
> useful to detect list abuse that has not been cought yet by other
> means.
I don't understand what CC lists have to do with abuse of the mailing
list -- any mail generated by a CC is done at the sender's mail server.
CC lists do not cause additional mail to be sent by lists.denx.de.
At worst, long-running threads can accumulate CCs that are no longer
relevant to where the thread has gone (and I'm fine with encouraging
those to be trimmed), but that's got nothing to do with the mailing list
itself. The only thing that having the list reject such mails will
accomplish is that people *not* on the CC list won't see the mail, which
is sort of the opposite of the intended effect.
>>> 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).
That problem is not caused by the CC lists, but rather the configuration
of the list server. What problem do the CC lists cause *by themselves*?
>>> 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.
>
> They could Cc: u-boot-addicts at foo.com (i. e. just one address) and
> distribute this internally to anybody who might be interested.
What would that accomplish (keeping in mind that the CCs are often not
for expanding the distribution list but calling specific people's
attention to the mail)? If those "addicts" were uniformly interested in
all u-boot mail, why wouldn't they just subscribe to the list? If
they're only interested in some threads, what makes you think it will be
the same set of "5 (or more)" people each time?
How should I know that someone wants to be CCed by some address other
than what they post with?
-Scott
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 22:00 ` Wolfgang Denk
2009-06-01 22:27 ` Scott Wood
@ 2009-06-02 0:09 ` T Ziomek
1 sibling, 0 replies; 14+ messages in thread
From: T Ziomek @ 2009-06-02 0:09 UTC (permalink / raw)
To: u-boot
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? |
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
2009-06-01 20:00 ` Wolfgang Denk
2009-06-01 20:32 ` T Ziomek
@ 2009-06-02 6:53 ` Stefan Roese
1 sibling, 0 replies; 14+ messages in thread
From: Stefan Roese @ 2009-06-02 6:53 UTC (permalink / raw)
To: u-boot
On Monday 01 June 2009 22:00:12 Wolfgang Denk wrote:
> > > there is an increasing number of postings with loooooong lists of
> > > recipients (10 addresses and more); usually several of these are
> > > regular and active users of this mailing list so this is actually
> > > redundant;
> >
> > It is not redundant -- including a person in the CC list brings the mail
> > to their attention faster (and with less chances of missing it) than if
> > they have to pick it out of the list.
>
> An email message is a message is a message, isn't it? The message on
> the list and the Cc: are identical, aren't they?
No, they not identical. For example my internal mail filtering will move all
mails directed to the list to a special u-boot list folder and those mails
addressed to me directly not. So I see all mails addressed to me in my inbox
which helps me to not miss anything relevant for me (ppc4xx etc).
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] REJECT: Too many recipients to the message
@ 2009-06-02 2:52 HeungJun, Kim
0 siblings, 0 replies; 14+ messages in thread
From: HeungJun, Kim @ 2009-06-02 2:52 UTC (permalink / raw)
To: u-boot
Dear Wolfgang & everyone,
It happened ?Too many recipients to the message?, and I'm very sorry that my messages's many CC cause this event.
Before that, I didn't find the recipients # limits on the u-boot mailinglist guidelines. So, I just send the messages like other my situation.
If It's hard to configure mailing list server, I think the warnning about?The limit of CC? is showed on the u-boot mailinglist guidlines or anywhere.
Thanks & Sorry.
Best Regards,
Riverful
----- ?? ??? -----
?? ??: T Ziomek <ctz001@email.mot.com>
?? ??: 2009? 6? 2? ??? ?? 9:09
?? ??: Wolfgang Denk <wd@denx.de>
??: Scott Wood <scottwood@freescale.com>; u-boot at lists.denx.de
??: Re: [U-Boot] REJECT: Too many recipients to the message
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? |
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-06-02 6:53 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2009-06-02 6:53 ` Stefan Roese
2009-06-02 2:52 HeungJun, Kim
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.