Mailman 3 August 2001 - Mailman-Developers

Re: List-CC?
by Joe Holt 27 Aug '01

27 Aug '01

This is an issue that I would very much like to find a solution for. As I understand it, most list admins set their lists to not accept email cc'ed or bcc'ed to the list. Very often I find myself wanting to send an event announcement or some such to several addresses (at least one of which is a list) without exposing everyone's email in the 'To:' header. I have to create a separate email for lists that use Mailman. I have actually never received a spam through an email list but it must be a problem for so many people to be taking actions to avoid it. Is it that difficult to verify the headers? What technical problems are at issue here? > At 11:32 AM 8/24/2001 -0400, Dale Newfield wrote: > > >I've got another fairly simple idea that I figured I'd throw out for > >comment. I was about to send a note to an announcement list I run, and > >thought "hey, I should also send this to Bob." Problem is, if I CC or BCC > >Bob, he gets the mail I send to Mailman rather than the mail that Mailman > >would send out (with the subscription info/footer/etc.) What would be > >cool is if there were a way to List-BCC: people instead of BCC:'ing them. > >Then Mailman would be the one to distribute extra copies, and they could > >be the same as messages seen by list-subscribers. > > Maybe I'm missing something but this sounds like a setup for a spam relay. > > - Ben

1 0

Read-only lists and per-user moderation
by Phil Stracchino 26 Aug '01

26 Aug '01

I see the question of the read-only mailing list has arisen yet again. How difficult would it actually be to add this functionality? I see two approaches to doing it. The first would be to just add a per-list "read-only" attribute. If this attribute is enabled, then the "Addresses of members accepted for posting to this list without implicit approval requirement" list becomes a list of users authorized to post to the list, period, and all other posts would be rejected automatically without generating an admin request to the list owner. The second, more flexible approach would be to add the per-list read-only attribute *and* add a per-user "Posting OK" flag to the Membership Management screen, which would default to on and could be set or cleared only by the list owner. Setting the list's read-only attribute would cause the "Posting OK" flag to be turned off for all existing members except the list owner, and cause all new subscriptions to have "Posting OK" turned off by default. This second implementation would also allow the list owner of a normal read-write list to selectively revoke posting privileges for list members without actually kicking them off the list. Used in this way, it would effectively amount to turning on moderation on a per-user basis without having to add all other members to the "approval not required" list. Reasons for doing this might include disciplinary measures for disruptive members, handling members who go on vacation with a vacation program set and forget to set their subscription to no-deliver, as a way to quickly squelch a flame war without having to turn on moderation for the entire list, or to set up a scheme of "probationary" members whereby posting privileges are not granted until a member has been subscribed for a specified period in order to learn the norms of accepted behavior on the list. Thoughts, opinions, flames? -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric(a)babcom.com halmayne(a)sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)

2 1

Re: [Mailman-Developers] List-CC?
by Ben Burnett 24 Aug '01

24 Aug '01

At 02:33 PM 8/24/2001 -0400, Dale Newfield wrote: >On Fri, 24 Aug 2001, Ben Burnett wrote: > > Maybe I'm missing something but this sounds like a setup for a spam > > relay. > >No more so than any mailing list--you can still have the same posting >restrictions. I'd use it so people can get a taste of what subscribing to >a given list is like w/o actually doing so. I guess I was missing something. For a moderated list this could be a neat feature. I also think that some people might receive the message and have no clue why they were included. They might think that they were subscribed by someone else, and get irate. Of course the list admins would then be subject to their wrath: "Why are you running a list that lets other people subscribe you without confirmation? I tried to unsubscribe, but it told me that I wasn't subscribed. Whats up with that!!" I think this could be cleared up with a "list sample" header/footer that was pre/appended to the message. Something like... ---- Greetings <recipientaddress>, This is a sample from the <listname> email list. Your friend <friendsaddress> who is subscribed to this list though you might be interested in seeing what goes on here. If you like what you see and would like to join the list just reply to this message with subscribe in the subject and you're all set. ---- Of course this seems like a little more work than just sending your message to the list and your friend, or if you really want them to get the entire list message, just wait for your copy from the list and forward it. - Ben

2 1

Re: [Mailman-Developers] List-CC?
by Ben Burnett 24 Aug '01

24 Aug '01

At 11:32 AM 8/24/2001 -0400, Dale Newfield wrote: >I've got another fairly simple idea that I figured I'd throw out for >comment. I was about to send a note to an announcement list I run, and >thought "hey, I should also send this to Bob." Problem is, if I CC or BCC >Bob, he gets the mail I send to Mailman rather than the mail that Mailman >would send out (with the subscription info/footer/etc.) What would be >cool is if there were a way to List-BCC: people instead of BCC:'ing them. >Then Mailman would be the one to distribute extra copies, and they could >be the same as messages seen by list-subscribers. Maybe I'm missing something but this sounds like a setup for a spam relay. - Ben

1 0

Re: [Mailman-Developers] Handling Bouncebacks
by J C Lawrence 24 Aug '01

24 Aug '01

On Thu, 23 Aug 2001 19:44:01 +0200 Norbert Bollow <nb(a)thinkcoach.com> wrote: > J C Lawrence <claw(a)kanga.nu> wrote: >> Does QMail always use single message envelopes when it is >> configured to deliver all outbound mail to a (single) smarthost? > Yes. Qmail always uses single message envelopes. Can it be configured *NOT* to? > In the Qmail world, smarthosting for mailing list traffic is > normally implemented with Ezmlm, in a way that is more efficient > than what you can done in any way with SMTP-based smarthosting. Which is not necessarily the point. With ISP's blocking outbound SMTP traffic and thereby forcing use of their smarthosts along with corporate network infrastructures and security models effectively ending at the same spot, the ability to use multi-address envelopes can be critical. I'm curious if this is a corner which Qmail is incapable is satisfying. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw(a)kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly

2 1

INTERNALANTENNAS.COM
by REBECCA GANDHEART 24 Aug '01

24 Aug '01

1 0

Re: [Mailman-Developers] Handling Bouncebacks
by J C Lawrence 23 Aug '01

23 Aug '01

On Thu, 23 Aug 2001 18:57:32 +0200 Norbert Bollow <nb(a)thinkcoach.com> wrote: > My point is that since Qmail always uses single-message envelopes > anyway, IF the MTA is Qmail, then it does _not_ cost you > _anything_ to use VERPs. Does QMail always use single message envelopes when it is configured to deliver all outbound mail to a (single) smarthost? -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw(a)kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly

2 1

Re: [Mailman-Developers] Handling Bouncebacks
by J C Lawrence 23 Aug '01

23 Aug '01

On Thu, 23 Aug 2001 16:56:56 +0200 Norbert Bollow <nb(a)thinkcoach.com> wrote: > If the MTA is Qmail, which supports VERP without any loss of > performance, VERPs should be used always. Performance is not the only concern or criteria. Bandwidth utilisation, mail routing (what says that the MTA Mailman delivers to is responsible for delivery to the final MX?), local resource consumption, and a small host of other concerns dictate this area far more than the choice of MTA. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw(a)kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly

2 1

Patching qrunner to never send duplicates w/ same Message-ID
by Ben Gertzfield 22 Aug '01

22 Aug '01

I'm interested in killing two birds with one stone; I'm presently moving a company's massive (> 1200 line) aliases file that has grown unmaintainable to Mailman, so that the sysadmins can let the list admins maintain their own subscriber lists. The one problem is that people at the company are used to Cc:ing multiple aliases and having only *one* copy of the email reach the final recipient, even if the recipient is a member of multiple aliases in the Cc: list. Sendmail would handle this internally with the old way of using one massive aliases file, because it would expand all aliases and only send one mail to each final address. This has been discussed before on mailman-users at http://mail.python.org/pipermail/mailman-users/2000-September/006880.html -- the answer there was of course "force the users to use a different MUA". Yes, I know the proper solution is to have the MUA ignore duplicate mails with the same Message-ID, but it's impossible to get a company to all switch to mailers that support this. I would like to work on a different solution; I think it might be possible to modify the Mailman queue runner to never send out multiple messages with the same Message-ID to the same recipient. Looking through the source in Mailman/Queue, I see that each mail's destination is put into its own marshalled .db file in /var/lib/mailman/qfiles, so we will have to keep state to avoid sending duplicates. The way Gnus (the best mail reader on the planet, natch) handles this is by keeping a cache of the past X Message-IDs (1000 by default, obviously tuneable); we could pretty easily keep a list of Message-IDs and recipient pairs, and do one of the following if a message is about to be sent out to a recipient that has already received an email with that Message-ID: 1) Do nothing. (to keep current behavior) 2) Add a warning header to let the users filter on their own 3) Don't send out the message. This could be configurable per-user, and I think it'd be a great improvement over the current state of things. Would a patch for this be accepted? At which point of the queue runner do we want to deal with this? Mailman.Queue.OutgoingRunner might be the right place, but I'm not sure. Ben -- Brought to you by the letters L and J and the number 12. "A calpac is a large cap." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/

4 12

Re: [Mailman-Developers] Handling Bouncebacks
by Dan Mick 21 Aug '01

21 Aug '01

> These questions should be easy. > The email blast goes out and the bads ones come back > to a specified address. Does Mailman run as a daemon > or are bouncebacks handles by piping through the > aliases file? Aliases lead to the processing commands. The bounces come to <listname>-admin@<hostname>. If you're talking about pre-2.1, see the comments at the head of cron/qrunner. Bounces go through the mailowner script (as a result of the alias). 2.1 and after use a different queue structure, essentially with daemons, but the daemons aren't listening for mail; they still get accessed via mail aliases which run programs which know how to send IPCs to talk to them. This stuff uses the Mailman/Queue code. Bounces still go through mailowner, but now mailowner calls the Switchboard queuing stuff. See Mailman/Queue/IncomingRunner.py for the diagram as it applies to 2.1.

1 0