Chris,

Sounds good, I'll be looking for your draft later on.

    I'm hoping to get the interface squared away soon at which point any

help would be wonderful for the conversion of mailman to use the interface and the development of any datasources that people would wish Mailman to use.

I'll be happy to help as I can, I can certainly help in the end step, step 4, by testing/converting the ACS to use your interface.

When you write,

Phase 3: Develop Php front-end for Archives/Admin utils

That makes me curious. I know Tcl (and C, LISP, etc.) but not Python or PHP. One reason for undertaking this project was to give me something "real" to focus on while learning Python. My understanding was that Python and PHP are somewhat competing technologies. Mailman is a Python tool right? What makes you choose Php for front-end development?

Thanks,

Jerry

At 12:16 PM 3/13/01 -0500, Chris Ryan wrote:

Jerry,

    Currently I'm working on developing code for Mailman that will allow

Mailman to work using any appropiate datasource. I plan on implimenting the flatfile (currently what is used today) and a PostgreSQL database datasource. I should have the first draft of the interface up on the Mailman ZWiki page by the end of the day. Stay tuned for more information on that.

    In regards to a Mail/Forum combination that is also one of my end

goals. The following plan is as such for entire layout:

Phase 1: Mailman uses database for configuration Phase 2: Mailman uses database for archives Phase 3: Develop Php front-end for Archives/Admin utils Phase 4: Incorporate/develop a forum ontop of previous changes

    In the spirit of open source the first 3 phases will be contributed

back to Mailman in some manner. I don't know all the details about phase 4 as of yet so I can't say if that will be contributed back or not as a usefull piece for Mailman.

    I'm hoping to get the interface squared away soon at which point any

help would be wonderful for the conversion of mailman to use the interface and the development of any datasources that people would wish Mailman to use.

Chris Ryan chris@greatbridge.com

Jerry Asher wrote:

...

I would like to unify mailman with an ACS bboard. The Open ACS (http://openacs.org) is a toolkit developing interactive community websites based on PostgreSQL and Tcl. ACS Bboards are just what they sound like, a discussion forum in which visitors to a site can post questions, or post answers to the questions that others have asked.

Currently the ACS system is such that visitors can request that follow up answers be sent to them, which the ACS implements by creating hundreds of individual emails and mailing them out. The "From" header is set to a bogus address (bboard-robot) and the Reply-To: header is set to the author of the new answer. Vacation messages get sent back to the author of the post. This means that if you reply to a message, the answer IS NOT posted on the bulletin board.

I would like to "unify" the ACS bulletin board code with "some" mailing list manager. The benefits to the ACS toolkit I perceive would include:

1 detecting/catching vacation messages 2 detecting/catching/(and maybe unsubscribing) bounces 3 ability to post directly to the bulletin from email (and have the posts end up in the right threads)

4 but I am worried about mail loops.

Can someone tell me "how well" Mailman performs at detecting/catching vacation and bounce messages?

I know little about mailing lists, or Mailman, or mail headers. But with a few pointers, I am willing to learn.

I wonder what the issues involved in this unification are? Are the four issues I am interested/worried significant enough that it makes sense to want to delegate this to Mailman? Or would it be easier/satisfactory to "just change the headers of the outgoing emails, and create some sort of procmail script to process new messages and post them into the right

thread?

...

If you feel that unification would be useful for my purposes, can someone tell me the right "places" in Mailman to get started? If I want to "inject" a message into Mailman for sending out to others, how would I do that? If I wanted to "capture" the incoming message for processing, where do I look for that? And how might I implement threading?

Thank you,

Jerry Asher

Jerry Asher jerry@hollyjerry.org 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers

===================================================== Jerry Asher jerry@hollyjerry.org 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688

Hi,

On Thu, Mar 15, 2001 at 10:32:38AM +0100, Thomas Wouters wrote:

On Tue, Mar 13, 2001 at 09:23:28AM -0800, Jerry Asher wrote:

...

...

Phase 3: Develop Php front-end for Archives/Admin utils

...

That makes me curious. I know Tcl (and C, LISP, etc.) but not Python or PHP. One reason for undertaking this project was to give me something "real" to focus on while learning Python. My understanding was that Python and PHP are somewhat competing technologies. Mailman is a Python tool PHP and Python aren't as competing with each other as Python and Tcl are :-) Seriously, though, I personally detest PHP. I've done a fair lot in it, and I hate it for a number of reasons, one of the more important ones being security (or lack thereof.) Python is a much, much easier language to program in, even for Web/CGI stuff, and if you are going to execute Python in the back anyway, it's not that much faster.

This makes me wonder... is there a mod_python for apache? or maybe fastcgi libs? would be interesting to have an extra choice to be able to run mailman in such an environment... especially if we get database support in the code; then it'd be good to be able to use persistant db links IMHO...

In a little defense for PHP, I think it's almost like perl; even though you know it has some issues it gets the job done very quickly easily and almost anything you want to do is available out of the box. Which I think it's one of the reasons why it grows so quickly... I don't agree with python being easier though :) For somebody new to programming it's easier to learn PHP than python... in some way PHP is just a huge number of available functions with a bit of programming language around it ;)

ps: sorry if my mesage is a bit messy; I have to get used to using mutt+vi again... I've given up my search for a stable gui mail client for now (again ;))

-- Regards,

Ricardo

On Fri, Mar 16, 2001 at 08:26:03AM +0100, Ricardo Kustner wrote:

This makes me wonder... is there a mod_python for apache? or maybe fastcgi libs? would be interesting to have an extra choice to be able to run mailman in such an environment... especially if we get database support in the code; then it'd be good to be able to use persistant db links IMHO...

There is a fastcgi lib for Python, and there are two Apache modules, mod_python and mod_snake. mod_python is less versatile, though, and I don't believe it allows Python embedded in HTML. mod_snake does, IIRC. mod_snake also allows deeply embedded Python (that is, Python code that can get into Apache internals, especiall Apache 2.0.) You can basically write Apache extentions using mod_snake and Apache 2.0.

In a little defense for PHP, I think it's almost like perl; even though you know it has some issues it gets the job done very quickly easily and almost anything you want to do is available out of the box. Which I think it's one of the reasons why it grows so quickly...

It gets the job done quickly, easily if the job is very small, and very *messy* :) Just consider the fact that you can call a php page using '<page>?var=value' and $var will be 'value' in the PHP page. End result: you can't trust variables :P

I don't agree with python being easier though :) For somebody new to programming it's easier to learn PHP than python... in some way PHP is just a huge number of available functions with a bit of programming language around it ;)

As a scripting language, PHP might be easier (I don't agree, but still.) But if you have no programming knowledge, or you want more than a quick hack to call a function, Python is definately easier.

ps: sorry if my mesage is a bit messy; I have to get used to using mutt+vi again... I've given up my search for a stable gui mail client for now (again ;))

Your lines seem to be wrapped at character 100 or so. Doesn't bother me, my editor (which, contrary to vi, is a real editor <wink>) does the paragraph reflowing for me :)

-- Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Sun, Mar 18, 2001 at 12:28:39AM +0100, Ricardo Kustner wrote:

On Fri, Mar 16, 2001 at 10:39:48PM +0100, Thomas Wouters wrote:

...

Your lines seem to be wrapped at character 100 or so. Doesn't bother me, my editor (which, contrary to vi, is a real editor <wink>) does the paragraph reflowing for me :)

which editor is that? I can't seem to figure it out from the message headers :)

It's 'joe', but it could have been (X)Emacs as well :) I haven't figured out how to teach (X)Emacs about quote characters yet, though. (joe recognizes common prefixes and takes them into account when doing paragraph reflowing. Say you have a text like

foo bar baz baz

and you type ^Kj while inside that paragraph, or you select the text and type ^Kj, it figures out '> ' is used to quote the paragraph and adjusts the string accordingly. So instead of

foo > bar baz baz

you end up with

foo bar baz baz

It fucks up occasionaly, and you don't want to do paragraph reflowing on a preformated paragraph (say, Python code examples :) but for replying to people with broken mailers/editors, it's +rock :) And besides, if it goes wrong, you do ^_ (undo :)

-- Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Sun, Mar 18, 2001 at 02:05:24AM +0100, Thomas Wouters wrote:

It fucks up occasionaly, and you don't want to do paragraph reflowing on a preformated paragraph (say, Python code examples :) but for replying to people with broken mailers/editors, it's +rock :) And besides, if it goes wrong, you do ^_ (undo :)

"par(1)".

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

...

...

...

...

"CR" == Chris Ryan <chris@greatbridge.com> writes:

CR> Phase 3: Develop Php front-end for Archives/Admin utils

It'd have to be a really really convincing argument[*] for me to add PHP to Mailman in any kind of supported way. As an add-on, sure, and figuring out the write API to put on Mailman to allow different web front-ends is definitely something that's important to me.

That's not to say that the CGI side of Mailman couldn't be vastly improved. I think there are good Pythonic solutions to this though.

[*]-50%-of-Guido's-bounty-for-adding-braces-to-Python-seems-about-right-ly y'rs,

-Barry

JA> Currently, the ACS bboard software, (uh, I believe) sends a
JA> new email to each individual.  Some have suggested that this
JA> in unnecessarily inefficient, that a smarter mailer (that
JA> might be found in a mailing list) might batch up the emails
JA> more efficiently.  Is that true?  Does mailman accomplish
JA> this?

Yes, in a way. Mailman isn't an MTA (i.e. mail transport agent, or smtp daemon), but it tries to cooperate with the MTA by handing messages off in batches. Ignoring optional chunking for the moment, let's say that you have a list with 1000 recipients. You could do like what it sounds ACS does and make 1000 separate connections to the local MTA, handing off a unique message per recipient. Or perhaps ACS tries to connect to each remote smtpd itself, in which case it has to handle all the problems of mail delivery normally best left to an MTA.

In Mailman, this message would be handed off to the local MTA as one copy, with 1000 recipients. Then it would be up to the MTA to do as efficient delivery as is possible. Mailman has some optional chunking parameters so that it can be tuned to your MTA, but in general, it tries to hand off the message with the fewest dialog with the MTA as possible, and then it gets out of the way.

JA> But also, the ACS bboard software doesn't do anything special
JA> with the headers that one *is supposed* to do for mailing
JA> lists.  For instance, you mention a "precedence: bulk" header
JA> to ward off properly configured vacation programs.  The ACS
JA> bboard doesn't do that, yet.  So unifying the ACS bboard with
JA> a maillist list manager that already implements proper header
JA> creation benefits the ACS wonderfully.

That sounds good. There are some other RFCs governing headers for mailing lists, and there are headers that are best removed, etc. Mailman's got all that.

JA> I think the plan (initally) would be for all mail and replies
JA> to go through Mailman just so the ACS can benefit from
JA> Mailman's having done this already, and Mailman's developers
JA> continuing interest in improving, or following new standards,
JA> etc.

Definitely doable.

JA> That sounds good.  Pardon my Mailman/Python ignorance, is
JA> there truly a procedure literally called email->bbs, or does
JA> this describe a "path" that mail can take?

That just describes the path of the mail.

JA> How do I do the reverse?  bbs->email?  (Just send an email to
JA> the list?)

Yep. It's as easy as having the bbs send the email to mylist@myhost.com. You /could/ inject it more directly, but you may not need to.

JA> How might I encode a piece of bbs data into an email such that
JA> replies to the email will carry that piece of data back?
JA> (that is, the specific thread/topic_id that the bbs should put
JA> the message into).  I realize I can do this by mangling the
JA> subject line for example:

JA> "Re: [thread: 2FC24] Mrs. Field's Recipes",

JA> but is there a more subtle/correct way to do this?  Perhaps by
JA> adding a header?  Or by mangling the reply-to address?

There's almost nothing you can do to an email message that you can guarantee will come back to you when someone replies to that message. MUAs (mail user agents, the thing a person uses to read and respond to their email) seems to have no lack of creativity in mucking up, adding, and deleting headers, or futzing with message bodies. I think you can be reasonably assured that Subject: mangling will mostly survive the round-trip, but that's about it. If you hack Reply-To: it's a good bet that you'll see that text come back at you in the To: or Cc: headers. I'm not sure what, if anything else you can rely on with enough certainty for your purposes.

JA> Qmail has wonderful behavior that supports my mangling of the
JA> reply-to address.  You can send a message to me at
JA> jerry@hollyjerry.org, or jerry-junk@hollyjerry.org, or
JA> jerry-webvan@ or you can put anything after the hyphen.  It
JA> will get to me all the same, OR I can set up qmail in a
JA> procmail like fashion to pass the message to a script which
JA> can filter the messages based on the data after the hyphen.
JA> So one way to encode the bbs thread data is to set the reply
JA> to "bboard-thread-2FC24@mybboard.com".

Postfix and Exim (and probably Sendmail) have similar functionality. That might not be a bad way to go.

JA> I found a recent copy of RFC 2076 that explains some of these
JA> headers, but can you point me to some documents that
JA> specifically what maillists are supposed to do including these
JA> ad-hoc standards?  Last night I was at the bookstore and
JA> flipped through an O'Reilly text: "Programming Email" - that
JA> sure didn't contain anything helpful.

Heh. RFC 2369 describes the List-* headers, and of course there's also the basic RFCs like 822, 1153, and the MIME RFCs. There's tons of useful lore on the net not covered in the RFCs. I'll try to find some time to put together a list of URLs I tend to consult, and add it to the Mailman docs.

JA> What specifies the behavior of a mail user agent in reply?  If
JA> I send a header, will the user agent include that header in a
JA> reply?

JA> Specifically, it appears I might encode some bboard message
JA> threading information in an X-URI, X-URL, or
JA> Content-Alternative headers.  "Should" a reply to a message
JA> containing those headers contain those headers?  From your
JA> answer regarding X-BeenThere, it sounds as though a "normal"
JA> reply should not include these headers....

Correct. See above. What specifies the behavior of an MUA is mostly the whim of the engineers who wrote the thing, near as I can tell. :)

Cheers, -Barry

On Sun, Mar 18, 2001 at 05:37:21PM -0800, Jerry Asher wrote:

Qmail has wonderful behavior that supports my mangling of the reply-to address. You can send a message to me at jerry@hollyjerry.org, or jerry-junk@hollyjerry.org, or jerry-webvan@ or you can put anything after the hyphen. It will get to me all the same, OR I can set up qmail in a procmail like fashion to pass the message to a script which can filter the messages based on the data after the hyphen. So one way to encode the bbs thread data is to set the reply to "bboard-thread-2FC24@mybboard.com".

Typical djb mistake. There's been a defined protocol for that that well predates qmail (unless I'm much mistaken); the defined character is a "+". No, it's not a formal standard... but it's apparently a widely defined informal standard.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015