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