Re: Need help with a recipe please.

At 12:57 2003-07-05 -0500, David W. Tamkin wrote:

> After reading Sean's reply (and Kreemy's), I still have this to say: how 
> do you prevent a member of A who is also on B from posting separate 
> dispatches of the same text [or a slightly altered text] to A and to B?
I'm keenly aware of that particular issue, though as the question was 
phrased "a single message", I figured the query was directed at a singular 
post with multiple list recipients.
> After all, you said that members of A are "allowed" -- not required, just 
> permitted -- to subscribe to B.  Therefore, there might be people on A who 
> have declined to join B, and a post to both A and B will reach people who
The one parallel that I can see is that perhaps the two lists are like a 
support list and a dev list, and developers may occasionally have a support 
list message forwarded into their list because it relates to a development 
issue (such as a bug), and therefore may need to be able to post to the 
support list in response, while support users are not permitted to post to 
the dev list.  Of course, in that particular example, I don't see why they 
shouldn't be able to post to the dev list as well, unless the support list 
messages are automatically forwarded into the dev list (which would be 
rather painful for the developers).
Lacking a better defined relationship between this magical "A" and "B" 
list, the above would probably suffice as a standard explanation as to 
their operation.  If people weren't so deliberatley vague, it'd be a LOT 
easier to help them sometimes.
In majordomo terminology, the B list would have a post-allow of the A and B 
list subscribers, while the A list would only have a post-allow of the A 
list subscribers.
[snip]

Pretty much all the pitfalls of a dual-list setup.

As for a common source of slight differences in separate posts with the 
same basic body content: random siglines will screw you every time.  In 
addition to the standard unix mailer .sigline setup, this may include 
advert siglines added by some mailers (or freemail services), as well as 
(if your lists allows for attachment/HTML content), A/V scanning signatures 
with unique "I scanned this message" keys.  Heck, just the MIME multipart 
separators would be unique from one message to the next.
> It is vanity, an attempt to herd the wind.
As I posted, it is much easier to spot the crossposted (as a single message 
to multiple recupients) messages and bounce them altogether, advising the 
sender to NOT crosspost.  It is my experience on other lists that most 
people who crosspost are too fsking lazy to bother with posting messages 
separatley, and generally that's the _responsible_ thing to do when a 
crosspost action is legitimately warranted, since it avoids crosspost 
replies (wherin the respondant hits [REPLY ALL] but isn't themselves 
subscribed to all the lists they're replying to).
For all we know, this crosspost followup is the reason for the desire to 
limit the posting addresses -- say because the user asking for this 
functionality is dealing with "nonmember submission" bounces from all the 
messages which bounce to the A list.  If so, perhaps the solution is to 
automate the nonmember submission bounces.  I do this on majordomo (with a 
procmail recipe), bouncing back text indicating that their message bounces 
because they are not subscribed to the list they tried to post to, and 
outlining the various reasons it might have bounced - replying to a 
crosspost; simply didn't complete the subscription process (and provide a 
link to a subscription page), posting from an address which receives 
forwarded email, or posting from an address other than the one you're 
subscribed to the list with (at work instead of home perhaps), etc.
Thus, I don't have to waste a single second on nonmember submission bounces 
- if I were so inclined, I could automatically trash the advisory copies of 
those which I recieve.
Sometimes, it helps to understand the underlying reason for needing a 
recipe in the first place.
---
 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