Block members from sending cc's and bcc's
Hi everyone,
Using Mailman 3 with Affinity web interface and we want to stop our members from sending to cc: or bcc:
We've found the Header Filter and cc and bcc appear in it. Tried to configure it to "hold for moderation," but it hasn't worked. Partly because we don't understand what to put in the Pattern input box. I put in cc: because it requires something.
Can anyone advise?
Cheers, Cathryn
On 6/23/25 10:04, Cathryn McGuire wrote:
Using Mailman 3 with Affinity web interface and we want to stop our members from sending to cc: or bcc:
We've found the Header Filter and cc and bcc appear in it. Tried to configure it to "hold for moderation," but it hasn't worked. Partly because we don't understand what to put in the Pattern input box. I put in cc: because it requires something.
The pattern box contains a regular expression that matches the value in
the header that you want to apply the action to. What you want is a
pattern that matches anything, e.g., .* to match zero or more
occurrences of any character.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
What you want is a pattern that matches anything, e.g., .* to match zero or more
occurrences of any character.
Please confirm that setting up a rule for cc's in Header Filter to "hold for moderation," it should block the member from sending a cc?
And, for the pattern, are you suggesting I use ".*" with cc: as the regexprs? Or, what exactly do I use under as a regular expression? Cathryn
Please confirm that setting up a rule for cc's in Header Filter to "hold for moderation," it should block the member from sending a cc?
It will hold for moderation any message containing a Cc: header. It won't prevent the moderator from accepting the message.
And, for the pattern, are you suggesting I use ".*" with cc: as the regexprs? Or, what exactly do I use under as a regular expression?
Use cc as the header and the two characters .* as the pattern (or whatever affinity calls it). See https://docs.python.org/3/library/re.html for information about Python regular expressions.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Sorry about the delay in getting back. Truth be known, I was a little burnt out from the merging of MM2 to MM3 and thought I might deal with it all later. Well, now is later.
The .* pattern did not do the job of blocking cc's and bcc's in the Header Filters of Affinity. It lets them go through, even as hold for moderation has been chosen.
I've asked EMWD to advise me because I think Affinity is very new, even though Brian Carpenter was developing it in 2020, is that correct?
If you have any more thoughts about this issue, I'd appreciate it.
Cheers, Cathryn
On 7/18/25 5:37 PM, Cathryn McGuire wrote:
The .* pattern did not do the job of blocking cc's and bcc's in the Header Filters of Affinity. It lets them go through, even as hold for moderation has been chosen.
First, you can't filter on Bcc because Bcc is removed from the message before being sent. That's the whole point of Bcc. In otherwords, if I mail To: the list with Bcc: to others, the list never sees that Bcc: header and can't filter on it.
As far as Cc is concerned, if in Header filters you have a rule with 'cc' in the header box and '.*' in the pattern box, the action box action should be applied to any message with a Cc: header.
I've asked EMWD to advise me because I think Affinity is very new, even though Brian Carpenter was developing it in 2020, is that correct?
Affinity is not new, but it is a proprietary product of EMWD. If you have set the header filter as above and it is not working, only EMWD can help with that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
- Since this post in July, I've been trying to work with EMWD to get the cc's blocked. I've tried every rule configuration in the Header Filter to no avail. EMWD can't seem to help. The setting options are as follows:
Acceptable aliases
This is a list, one per line, of addresses and regexps matching addresses that are acceptable in To: or Cc: in lieu of the list posting address when 'require_explicit_destination' is enabled. Entries are either email addresses or regexps matching email addresses.Regexps are entries beginning with '^ and are matched against every recipient address in the message. The matching is performed with Python's re.match () function, meaning they are anchored to the start of the string.
- Require Explicit Destination (this is a checked box. Could it be interfering with the Header filters?)
This checks to ensure that the list posting address or an acceptable alias explicitly appears in a To: or Cc: header in the post.
- Default action to take when a member posts to the list
Accept immediately (bypass other rules) Default action to take when a member posts to the list. Hold: This holds the message for approval by the list moderators. Reject: this automatically rejects the message by sending a bounce notice to the post's author. The text of the bounce notice can be configured by you. Discard: this simply discards the message, with no notice sent to the post's author. Accept: accepts any postings without any further checks. Default Processing: run additional checks and accept the message. NOTE - when set here, all members are blocked.
- We also have the problem of large image file sizes being let through no matter what setting we have. We have it set to 500KB, but everything is accepted.
Maximum message size 500 The maximum allowed message size in KB. This can be used to prevent emails with large attachments. A size of 0 disables the check.
Perhaps some settings are over-riding others?
What do you think?
Best, Cathryn
On 10/19/25 14:28, Cathryn McGuire wrote:
Hi Mark,
- Since this post in July, I've been trying to work with EMWD to get the cc's blocked. I've tried every rule configuration in the Header Filter to no avail. EMWD can't seem to help. The setting options are as follows:
Acceptable aliases
This is a list, one per line, of addresses and regexps matching addresses that are acceptable in To: or Cc: in lieu of the list posting address when 'require_explicit_destination' is enabled. Entries are either email addresses or regexps matching email addresses.Regexps are entries beginning with '^ and are matched against every recipient address in the message. The matching is performed with Python's re.match () function, meaning they are anchored to the start of the string.
What is the content of this? Probably should be empty.
- Require Explicit Destination (this is a checked box. Could it be interfering with the Header filters?)
No, it doesn't interfere with header checks.
This checks to ensure that the list posting address or an acceptable alias explicitly appears in a To: or Cc: header in the post.
- Default action to take when a member posts to the list
Accept immediately (bypass other rules) Default action to take when a member posts to the list. Hold: This holds the message for approval by the list moderators. Reject: this automatically rejects the message by sending a bounce notice to the post's author. The text of the bounce notice can be configured by you. Discard: this simply discards the message, with no notice sent to the post's author. Accept: accepts any postings without any further checks. Default Processing: run additional checks and accept the message. NOTE - when set here, all members are blocked.
What does Blocked mean? If you mean held for moderation, what is the reason they are held?
- We also have the problem of large image file sizes being let through no matter what setting we have. We have it set to 500KB, but everything is accepted.
Maximum message size 500 The maximum allowed message size in KB. This can be used to prevent emails with large attachments. A size of 0 disables the check.
Perhaps some settings are over-riding others?
If you have Default action to take when a member posts to the list set to Accept, that bypasses this check and many others.
What do you think?
What do you have in your header filter rules?
More importantly, what are you trying to accomplish? I.e. what do you want to happen in the following cases?
Message To: the list, no Cc:
Message To: the list, Cc: to other address
Message To: somewhere else, Cc: to the list
Message To: elsewhere, Bcc: to the list (require explicit destination will hold this one)
Maybe others?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
You: What is the content of this? Probably should be empty. Me: It is empty.
You: No, it doesn't interfere with header checks. Me: Okay.
You: What does Blocked mean? If you mean held for moderation, what is the reason they are held?
Me: We've changed from Accept Immediately to Default Processing. We'll investigate other settings that might be making all message Held.
You: If you have Default action to take when a member posts to the list set to Accept, that bypasses this check and many others. Me: As above--changed from Accept to Default Processing. File sizes should be limited now.
You: What do you have in your header filter rules?
More importantly, what are you trying to accomplish? I.e. what do you want to happen in the following cases?
Message To: the list, no Cc: -- Accepted
Message To: the list, Cc: to other address (non-member) -- Hold for moderation.
Message To: the list, Cc: to a member's address –– Accepted
Message To: somewhere else, Cc: to the list -- Hold for moderation.
Message To: elsewhere, Bcc: to the list (require explicit destination
will hold this one) -- Hold for moderation.We're no longer concerned about Bcc because you explained it before. It's in the subject line here, but we're not concerned about it.
Thanks Mark, Cathryn
On 10/20/25 17:50, Cathryn McGuire wrote:
Me: We've changed from Accept Immediately to Default Processing. We'll investigate other settings that might be making all message Held.
The important thing is the reason why the message is held.
More importantly, what are you trying to accomplish? I.e. what do you want to happen in the following cases?
Message To: the list, no Cc: -- Accepted Message To: the list, Cc: to other address (non-member) -- Hold for moderation. Message To: the list, Cc: to a member's address –– Accepted
I don't think you can accomplish this one. You can hold all messages with a Cc: header with header filter which is close to what you want, but this won't distinguish between members and nonmembers in the Cc: header.
There are other cases you might want to address such as multiple values in To:, one of which is the list and another is a nonmember, but I don't think you can accomplish that either. The best you can do in this case is a header filter on To: with a pattern that matches multiple addresses and a hold action. Such a pattern might be something like
.*?@[^,]*,.*@
which will match anything up to the first @ followed by anything up to a comma followed by anything up to another @. The idea is it will match anything with two or more strings containing @ and separated by a comma.
Message To: somewhere else, Cc: to the list -- Hold for moderation. Message To: elsewhere, Bcc: to the list (require explicit destination will hold this one) -- Hold for moderation.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 10/20/25 17:50, Cathryn McGuire wrote:
More importantly, what are you trying to accomplish? I.e. what do you want to happen in the following cases?
Message To: the list, no Cc: -- Accepted Message To: the list, Cc: to other address (non-member) -- Hold for moderation. Message To: the list, Cc: to a member's address ?? AcceptedI don't think you can accomplish this one.
I agree with Mark -- I don't see how to do this without changes to the code. Also, note that even if you could configure this as you desire, the CC addresses will be delivered. But people who subscribe but aren't CC'd will receive the post only if and when the post is released from hold. Only you can decide whether that's desirable, but it's likely some subscribers will be unhappy about it.
If preventing subscribers from getting duplicates is a reason for these settings, there is a user option (I think it's "Not Me Too") that suppresses list distribution to subscribers whose addresses are in To or CC. The list owner can set this manually, one by one. The site owner (who can log in on the host) can use a simple script to do so. When this is set, only the direct message (without list decorations in Subject or footer) is received by CC'd subscribers. This probably won't affect MUAs that organize posts into threads (conversations), but may look odd to subscribers if your lists are configured to add tags or serial numbers to the Subject.
If the point is to discourage resending list posts to third parties, about all you can do is use the anonymous list option to clean all addresses except the list's out of the header. "Full personalization" will substitute the subscriber's address for the list address, but I don't think it has any effect on third party addressees.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 10/20/25 23:21, Stephen J. Turnbull wrote:
I agree with Mark -- I don't see how to do this without changes to the code. Also, note that even if you could configure this as you desire, the CC addresses will be delivered. But people who subscribe but aren't CC'd will receive the post only if and when the post is released from hold. Only you can decide whether that's desirable, but it's likely some subscribers will be unhappy about it.
This is an important point.
If your goal is to prevent exposing those non-member addresses in Cc:, etc. in posts from the list, then all this may help, but if your goal is to prevent list posts from going to non-members, you can't accomplish that. by the time mailman receives and perhaps holds the post, it will already have been sent to all the directly addressed To:, Cc: and Bcc: recipients.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Cathryn McGuire writes:
- Since this post in July, I've been trying to work with EMWD to get the cc's blocked.
It is unclear to me what you mean. If you want to prevent non-list addresses from appearing in the header of list posts as distributed, you can configure the list as anonymous (in which case it will appear to be From the list), or you could do something more complicated to remove those headers. See Mark's questions about "what do you want to happen when ..." in his parallel post. Note that BCCs never are seen by your host's mail server or by Mailman -- that is what the "blind" in "blind carbon copy" means.
If you want to prevent recipients of list posts from sending additional copies directly to personal addresses visible in the mail header, you're out of luck. You cannot block CCs or BCCs. They go directly from the person composing the message to the addressees. You could create a configuration where the list refuses to distribute messages with explicit addressees who are not the List Post or an Acceptable Alias, but those addressees would still get the CCs. And you can't do anything about BCCs, because your mailserver and Mailman never see those at all.
The only effective way to *prevent* these extra copies is to suspend or ban users who do it. The best way to handle it is to teach your subscribers to de-duplicate their email. Most mail clients have a feature to do this.[1] Some email providers will do this for you (I think Gmail does?)
Acceptable aliases
This is a list, one per line, of addresses and regexps matching addresses that are acceptable in To: or Cc: in lieu of the list posting address when 'require_explicit_destination' is enabled.
This means that these addresses satisfy the requirement that the list be explicitly addressed (no BCCs to the list). It does not mean that posts with addressees who are not the list will be rejected.
- Require Explicit Destination (this is a checked box. Could it be interfering with the Header filters?)
This means No BCCs To The List.
- Default action to take when a member posts to the list
Accept immediately (bypass other rules)
This is why your size filter has no effect.
Default Processing: run additional checks and accept the message. NOTE - when set here, all members are blocked.
You need to figure out why this is happening. See Mark's parallel post for some useful questions to diagnose it. Most important, check all the header filters.
Footnotes: [1] The usual implementation is to delete or suppress later messages with the same Message-ID. Unfortunately, the first to arrive is usually the CC or BCC copy, which lacks the list's "decorations" on distributed posts. A few subscribers are sensitive to this inconsistency, and they'll have to make a choice. I recommend that list owners should not use this feature if the list copy will be deleted.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hello Stephen,
Read and understood.
We're reset the Message Acceptance to Default Processing and the checks will be run. If ALL messages are Held for Moderation, we'll investigate why (some other settings that are taking precedence).
Meanwhile, I answered Mark above on the questions he asked.
Thanks for your informative answers, once again. Cathryn
On 6/23/25 10:04, Cathryn McGuire wrote:
Hi everyone,
Using Mailman 3 with Affinity web interface and we want to stop our members from sending to cc: or bcc:
You won't ever see a Bcc: header in mail to a list. The whole point of Bcc: is to not expose the additional recipients or the fact that there were additional recipients so the sending MUA includes the Bcc recipients in the SMTP RCPT TO commands, but drops the Bcc: header from the message.
I.e., There is no way to know whether the original sender included Bcc: recipients or not.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark and Stephen,
You answered abouit Bcc's long ago in this string, we're no longer looking to amend anything to do with Bcc's.
All we're trying to do is stop posts with cc's from going to the list. We know that the cc will go to the outside recipient and there's nothing to stop that because it's being sent by the member from their own client email.
Since setting to Default Processing, ALL members posts are being held for moderation. That's what happened last time. Obviously there's some setting somewhere that's telling the list to do that with that setting. We'll try to find it by doing testing like you said. Meanwhile, we're quite busy in our other endeavours and having to unblock every post (some days more than others, and not that many relatively speaking) is what we're doing.
I will get back to you once we have a breather and can do that testing. I'm hoping we can find the issue. Won't know until we try.
So good of you to help us deal with this.
Best, Cathryn
On 10/26/25 10:38, Cathryn McGuire wrote:
Since setting to Default Processing, ALL members posts are being held for moderation. That's what happened last time. Obviously there's some setting somewhere that's telling the list to do that with that setting. We'll try to find it by doing testing like you said. Meanwhile, we're quite busy in our other endeavours and having to unblock every post (some days more than others, and not that many relatively speaking) is what we're doing.
What is the reason given for the post being held? I don't know about affinity, but Postorius gives the reason in the list of held messages. Also the message itself has a X-Mailman-Rule-Hits: header that says which rule caused the message to be held
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Many of them say:
The message is being held because:
Message has more than 1 recipients Post to a moderated newsgroup gateway
But there's no cc showing. Could be a bcc, but we wouldn't be able to tell. We don't think so, though.
- The following are new today (makes us wonder if EMWD is working on something):
The message is being held because:
Header "neighbours<neighbours@mailist.dunbar-vancouver.org>" matched a header rule
Saw the cc when we opened the message.
So, two things are happening with respect to cc's and Default Processing. 1) cc's are being held now, and 2) everything is still being held.
Thanks Mark, Cathryn
On 11/6/25 16:21, Cathryn McGuire wrote:
Many of them say:
The message is being held because:
Message has more than 1 recipients
I don't know where in affinity you find this setting, but there is a setting for Maximum number of recipients which is set to one and that is exceeded. This setting may be intentional on your part.
Post to a moderated newsgroup gateway
There are also settings for a newsgroup gateway. These settings should be
Gateway to mail No Gateway to news No Linked Newsgroup empty Newsgroup moderation not moderated
It appears in your case that Gateway to news is Yes and Newsgroup moderation is Moderated.
But there's no cc showing. Could be a bcc, but we wouldn't be able to tell. We don't think so, though.
- The following are new today (makes us wonder if EMWD is working on something):
The message is being held because:
Header "neighbours<neighbours@mailist.dunbar-vancouver.org>" matched a header rule
Saw the cc when we opened the message.
Was the Cc: to <neighbours@mailist.dunbar-vancouver.org>?
If so this is a match to your Cc: header filter, and the reason should be
Header "cc: <neighbours@mailist.dunbar-vancouver.org>" matched a header rule. If the reason was actually what is posted above with 'neighbors' rather than 'cc:', that's a problem with EMWD's Mailman core.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
"It appears in your case that Gateway to news is Yes and Newsgroup moderation is Moderated"
I don't see any Gateway to mail or Gateway to news, but Newsgroup moderation was set to Moderated (as you said). I changed it to Not Moderated.
In the following case, they are cc'ing to the mailist, and To: is to a member. Sometimes they are not members. Sometimes they To: to the mailist and cc: to the member or non-member.
Subject:Re: [Neighbours] Furnace problems To:Bill McCreery <billmccreery1@gmail.com> Cc:neighbours@mailist.dunbar-vancouver.org Content-Type:multipart/alternative; boundary="000000000000f9e5900643322d20" X-MailFrom:dunontime@gmail.com X-Mailman-Rule-Hits:header-match-neighbours.mailist.dunbar-vancouver.org-0 X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation
"If the reason was actually what is posted above with 'neighbors' rather than 'cc:', that's a problem with EMWD's Mailman core."
Does that mean that any cc: to neighbours or to a member or non-member should be blocked (held)? Or, does that mean if the cc: is to neighbours, it should be allowed through?
Sorry, not understanding what you mean?
Thanks again, Cathryn
On 11/14/25 15:36, Cathryn McGuire wrote:
Hi Mark,
"It appears in your case that Gateway to news is Yes and Newsgroup moderation is Moderated"
I don't see any Gateway to mail or Gateway to news, but Newsgroup moderation was set to Moderated (as you said). I changed it to Not Moderated.
That's good. As I've said, I don't know what the affinity UI looks like. If you send me (off list) a screen shot of the page where you see Newsgroup moderation, I can advise you further, but basically, anything to do with Newsgroups should be set to Off or No.
In the following case, they are cc'ing to the mailist, and To: is to a member. Sometimes they are not members. Sometimes they To: to the mailist and cc: to the member or non-member.
Subject:Re: [Neighbours] Furnace problems To:Bill McCreery <billmccreery1@gmail.com> Cc:neighbours@mailist.dunbar-vancouver.org Content-Type:multipart/alternative; boundary="000000000000f9e5900643322d20" X-MailFrom:dunontime@gmail.com X-Mailman-Rule-Hits:header-match-neighbours.mailist.dunbar-vancouver.org-0 X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation
My understanding is you want to hold for moderation any message with a Cc: unless it it To: the list with a Cc: to a member, and I said that with what's available to you in the list's settings, you can't distinguish between Cc: to a member and Cc: to a nonmember, so you have to hold any message with a Cc:
"If the reason was actually what is posted above with 'neighbors' rather than 'cc:', that's a problem with EMWD's Mailman core."
Does that mean that any cc: to neighbours or to a member or non-member should be blocked (held)? Or, does that mean if the cc: is to neighbours, it should be allowed through?
That quote was in response to your post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... wherein you said
The message is being held because:
Header "neighbours
<neighbours@mailist.dunbar-vancouver.org>" matched a header rule
I thought that was a typo and the real reason was
Header "Cc: <neighbours@mailist.dunbar-vancouver.org>" matched a header rule.
If that was the case, it was expected and was due to your header filter on Cc: headers. My confusion was I couldn't see how the reason could have been
Header "neighbours <neighbours@mailist.dunbar-vancouver.org>" matched a header rule.
And if it was, that was an EMWD issue.
I think the header rule you have will hold any post with a Cc: to anywhere. If you want to not hold posts with a Cc: <neighbours@mailist.dunbar-vancouver.org> regardless of To:, you can do that by adjusting your header rules, but I don't think you want that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
"I think the header rule you have will hold any post with a Cc: to anywhere. If you want to not hold posts with a Cc: <neighbours@mailist.dunbar-vancouver.org> regardless of To:, you can do that by adjusting your header rules, but I don't think you want that."
Our members are suddenly sending To: member or non-member and Cc: to our list (neighbours):
From:Caroline Astell <astell@shaw.ca> MIME-Version:1.0 Subject:Re: [Neighbours] Re: Telus Landline Question Date:Fri, 14 Nov 2025 17:47:10 -0700 (MST) Message-Id:<2DD7F314-971B-41AB-9A62-CB14D575C11A@shaw.ca> References:<CAAGK_erkMQx=R+ita4KU-M2msvXaQFWjiM5=ssjDMpb-4WrVpw@mail.gmail.com> Cc:neighbours Mailist Dunbar <neighbours@mailist.dunbar-vancouver.org> In-Reply-To:<CAAGK_erkMQx=R+ita4KU-M2msvXaQFWjiM5=ssjDMpb-4WrVpw@mail.gmail.com> To:Beverly Dunne <dunontime@gmail.com> X-Originating-IP:[72.143.235.33, 72.143.235.33] X-Mailer:Zimbra 10.1.10_GA_4785 (MobileSync - Apple-iPhone12C1/2207.100) Thread-Topic:Telus Landline Question X-MailFrom:astell@shaw.ca X-Mailman-Rule-Hits:header-match-neighbours.mailist.dunbar-vancouver.org-0 X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation
So, I think it's like you said: "the header rule will hold any post with a Cc: to anywhere."
You hinted there's a way to not hold posts with a Cc: to <neighbours@mailist.dunbar-vancouver.org> by adjusting our header rules, but I think yes, now we do want that. What would that header rule look like?
Thanks Mark, Cathryn
On 11/14/25 17:34, Cathryn McGuire wrote:
You hinted there's a way to not hold posts with a Cc: to <neighbours@mailist.dunbar-vancouver.org> by adjusting our header rules, but I think yes, now we do want that. What would that header rule look like?
You can use the following rule:
Header = cc Pattern = ^(?!(\w+ )*<?neighbours@mailist.dunbar-vancouver.org>? *$) Action = Hold for moderation
That will match any Cc: header that doesn't look like any of
Cc: <neighbours@mailist.dunbar-vancouver.org> Cc: neighbours@mailist.dunbar-vancouver.org Cc: neighbours Mailist Dunbar <neighbours@mailist.dunbar-vancouver.org> Cc: any words <neighbours@mailist.dunbar-vancouver.org>
That will probably be good enough.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Teilnehmer (3)
-
Cathryn McGuire -
Mark Sapiro -
Stephen J. Turnbull