Re: [Evolution] Filtering out duplicate messages

[simran <simran list leonardchristian com>]

Personally i think the evolution team is making a very sensible
decision. 

If the "feature" were include, i can just image the emails on this
list... with people complaining about mailings going missing etc... 

If you though this feature is a "must have" though, then you can
implement it a myriad of ways... including: 

  * Changing the source code for yourself

  * Create a filter that pipes all messages to a script that you create
    which: 
          - checks to see if a message with the same id has already been
            received... 

            if (yes) then 
               exit with some code that your filter caches and acts on
            else 
               stores the message-id of the message piped to it
            endif

           Such a script - at least in perl would only be 10-20 lines. 

On Tue, 2003-01-21 at 09:25, William X Walsh wrote:
> On Sun, 2003-01-19 at 03:01, Alessio Bragadini wrote:
> > On Sat, 2003-01-18 at 14:26, ahimsa wrote:
> >
> > > With a couple of the lists that I belong to I am finding that I am
> > > getting two messages - duplicates - and was curious if anybody had found
> > > a way to filter out the duplicate using Evo's filters? If so, what
> > > worked for you.
> >
> > Please search in the list archives, there have been a number of detailed
> > threads about this. In short: Evo developers feel there is not a safe
> > algorithm to identify "duplicate messages", so they don't believe this
> > should be done in Evo. Message-Id headers are not, per se, guaranteed to
> > be unique on your entire mailbox, although in most cases are.
>
> Fine, then warn the user about the possible consequences, and let the
> user decide if they want to implement it or not.  That it might not work
> as planned in a VERY limited number of cases (especially as rarely as
> this case is likely to occur) seems like a very poor reason to not
> include the feature.
>
> The developers should want to provide the most functionality possible,
> and let the users decide what functionalities they actually use. 
>
> I hope Evolution does not go down the path I've seen other open source
> projects go down, and use control over the features implemented to
> enforce THEIR view of how things SHOULD be done, and instead let the
> users have the options on whether the features are ones they want to
> enable or not.