At 20:39 2002-06-13 -0500, David W. Tamkin did say:
Sean Straw answered,
| Uhm, are you suggesting that you globally filter a message out because SOME
| OTHER user already received it?
... or is also receiving it at the same time ...
Equally valid, but what I was saying was intended to reinforce the
following sort of scenario:
UserA: list1 & list2
UserB: list2, perhaps direct cc: on message there as well.
Someone sends a message to list2 & cc's userB, and the cc: arrives first
(which is fairlylikely just because of listserve delays), that messageID
ends up in the cache. Now, the message through list2 arrives, but having
already been seen here, it is discarded -- depriving UserA of ever
receiving email they should have received.
OR, a message is crossposted to list1 & list2. The copy from list1
arrives, and is delivered to UserA. The copy from list2 arrives, but since
the ID appears in the cache, it is discarded - depriving UserB of their
legitimate email.
The number of opportunities for users to get screwed goes up significantly
as the number of users exceeds two.
You won't reduce your inbound email traffic hit in any event, since the
message will have been received in full before being processed in this
fashion. What you risk is improperly tossing messages which one user or
another SHOULD have received, but will not because the message ORIGIN
duplicates that of another message already received (but not necessarily
delivered to the same set of recipients).
List1 and List2 may tweak Subject: headers and quite possibly change the
reply-to: - so depending upon the order which messages arrive, so even if
you weren't depriving a user of the message content, by blocking the copy
routed by another list (to which they're a subscriber), you may deprive
them of the natural reply order they would have on THAT list on which they
actually participate.
| I can't advise that.
Neither could I, unless the "users" are an assortment of accounts used by a
grand total of one person.
Which isn't the impression that was given, but if this is actually the
case, it should be made clear.
The best one could probably do is have a user-based messageid cache (you're
still more or less arbitrarily tossing messages from different lists on
their behalf though):
[in /etc/procmailrc, or a script includerc'd into it]
:0 Wh: msgid.$LOGNAME.lock
| formail -D 8192 msgid.$LOGNAME.cache
This would manage a separate messageid cache for each user.
I'd still personally advise against doing such a thing on behalf of your
users: it'll cause more problems than it will solve (what exactly are you
trying to solve again anyway?).
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail