[Mailman-Developers] mailman and the web

[Barry A. Warsaw]

    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