On Fri, 21 Mar 2014 13:41:54 +0100
"J. Roeleveld" <jo...@antarean.org> wrote:
> On Fri, March 21, 2014 12:59, Tom Wijsman wrote:
> > On Fri, 21 Mar 2014 12:50:23 +0100
> > "J. Roeleveld" <jo...@antarean.org> wrote:
> >
> >> Tom,
> >>
> >> Please reply to list. No need to include me in the recipient list.
> >
> > Please filter duplicate mails. No need to tell each other this.
>
> I filter on the server, using SIEVE-scripts.
> Please provide the correct syntax I need to do this.
The vnd.dovecot.duplicate extension can be used to do this, RFC:
http://hg.rename-it.nl/dovecot-2.1-pigeonhole/raw-file/tip/doc/rfc/spec-bosch-sieve-duplicate.txt
It is designed exactly for this purpose, quote from the introduction:
Duplicate deliveries are a common side-effect of being subscribed
to a mailing list.
Example correct syntax:
require ["vnd.dovecot.duplicate", "fileinto", "mailbox"];
if duplicate {
fileinto :create "Trash/Duplicate";
}
This will move duplicates to Trash/Duplicate, given that you enable the
vnd.dovecot.duplicate extension; I use a similar rule in procmail.
> You are the only one causing duplicate emails, all others on this
> list do NOT cause duplicate emails.
That's because some people here are users that don't commonly use
bigger mailing lists and thus have no such filter in place; however,
when you get to participate in bigger mailing lists, you will get such
duplicate mails by design if you don't have a filter. Take for example
the LKML, where it is common practice that relevant mailing lists as
well as individuals are CC-ed; you'll get a dupe as one of either.
Being the sender of a message, however, some mailing lists allow you to
control whether you want to be CC-ed; this can be done by setting a
"Reply-To header", but in this case it is always overridden which
removes the ability to guarantee you'll receive the message.
There are other participants on the Gentoo mailing lists that
participate in other mailing lists too; and when met with Reply-To
mungling, they do the same approach. eg. Michał Górny (mgorny)
> This means the cause is on your side and the solution should then
> also be on your side.
The goal is to ensure people receive their mail; if I were to make a
solution on my sight, it voids that goal as the guarantee is gone.
> > http://www.unicom.com/pw/reply-to-harmful.html
> > http://woozle.org/~neale/papers/reply-to-still-harmful.html
>
> I disagree with those. Seen those arguments before along with the
> opposite versions. Mailing lists where a reply does not work are
> broken. Mailing lists where I always end up with duplicate replies
> don't stay used by myself for very long.
Given a present filter, I use any mailing list; I don't let technical
differences in the software being used overcome the ability to state
something on a mailing list, and if a technical difference does matter
to someone (0.1% in this case) I expect them to adapt. This ain't a
place where "One True Way" is to be enforced; as you can see, I very
well consider the standard reply button to be broken...
> >> Also, no need to reopen a closed mail
> >
> > A thread can't be closed by its individuals; you can choose to not
> > reply, but that doesn't withhold the ability for others to reply.
>
> True, but a mail-thread that hasn't had a reply for over a month is
> usually considered closed. It's nice that you decide to catch up with
> your emails, but please then take care not to flood inboxes as well.
Similar to above, right click and "ignore thread" could be used as
well as "sort / group by thread"; as without both features, there's no
dam in place to avoid the flood from happening.
As for the river / sea, there's no way to convince the river / sea to
go away; it'll be there, even if you could use a bucket to remove me,
there'll be another person or so tomorrow.
In comparison, on the LKML you will get replies one or more months
later; if you there then reply claiming a thread is closed, it'll be
perceived as everything but that...
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
