On Mon 05 Feb 2018 at 10:24:14 -0500, The Wanderer wrote: > On 2018-02-05 at 10:09, to...@tuxteam.de wrote: > > > On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote: > > > >> On 2018-02-05 at 09:32, David Wright wrote: > > > > [...] > > > >> > :0 Wh: $HOME/msgid.lock > >> > | formail -D 199999 $HOME/msgid.cache > >> > > >> > I used it for years. > > > >> I don't parse this well enough to understand what it would do, and I > >> don't know where to find a procmail reference which would let me read up > >> on it easily enough to understand quickly. Could you clarify? > > > > The trick is in formail (contained in the package procmail). Formail is > > a pretty generic mail parser which can be used to filter mails (or parts > > of mails) according to different criteria. Option -D instructs it to set > > up a Message-ID cache to drop duplicate mails (duplicate in the sense of > > Message-ID, that is). The number after the -D limits the cache's length. > > That wouldn't produce the behavior I want, though. Whether or not a > "duplicate" private copy (or probably not actually duplicate, since > mailing lists tend to modify other headers while leaving Message-ID > alone) is inappropriate depends on context, and specifically, primarily > on the sender's intent.
Intent is something difficult to work out. I suspect many just hit mutt's equivalent of the "g" key. Getting upset about it is the road to a flame war. > There can be legitimate reasons to send a message both to mailing list > and to a named recipient who is also subscribed to that list. Indeed. > For example, consider a high-volume mailing list, where many subscribers > read only part of the traffic. Or, could we consider the BTS? Not Cc'ing a bug report submitter in a reply runs a very high risk of leaving them out of the loop. > If there's an ongoing discussion on that mailing list, and one of the > participants wants to draw in a third person who also subscribes, it's > entirely appropriate to CC a reply to that third party. Definitely (whether they are known to subscribe or not). Which brings us back to - how does one know someone is subscribed to a Debian mailing list? > However, if this were to happen with me, I would not want to receive > *only* the mailing-list copy. I would want to receive both: the > mailing-list copy to go into my local archive of the mailing list (and > to be present in the mailing list's folder, so that it appears properly > threaded with other replies), and the direct copy to draw my attention > to the subject. (Although I would probably then seek out the > mailing-list copy and reply to that. But that's a personal > idiosyncrasy.) Seeking out is time-consuming. A recipe for automation is given in another post. It gives you everything you want. > There are other possible complexifying scenarios, which distort the > picture in other directions, but I don't have them ready to mind right > now. I've tried to point to some of them. > What it boils down to is that dropping duplicate messages is only always > appropriate when they are *complete* duplicates, in all headers (except > possibly things like transmission path history). With a mailing list, > that's rarely if ever the case. (Transmission headers are not unimportant. You cannot have it both ways; it's either a duplicate or it's not). It's probably impossible. Determining a duplicate email solely on the basis of an identical Message-Id: is a brain-dead idea. -- Brian. -- Brian.
