Re: Need help with a recipe please.
2003-07-05 12:19:09
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
|
|