Re: being flexible.
On Fri, 31 Oct 2003 10:21:20 +0100 Simone Piunno <pioppo@ferrara.linux.it> wrote:
Alle 01:51, venerdì 31 ottobre 2003, J C Lawrence ha scritto:
A test installation (or a poor man's installation) will fetch messages from pop3 mailboxes...
Hell no. Mailman is a conformant well behaved and very standard mail system, not a hack on top of a kludge that deliberately flouts the standards just because it wants to.
Hehe, I knew you'd have screamed :)
Aye, its a lot of fragile and unnecessary work that encourages a use of mailman which I'd rather never occurred.
Try to think it the other way: a test installation with pop3 is an hack on top of a solid conformant well behaved and very standard mail system.
Right, but the information lost across the non-SMTP translation is irretrievable and necessary.
Skilled people can do it right now with Mailman 2.1: just configure fetchmail to act as an MTA and pipe messages to Mailman. The only difference I proposed is that non-skilled people should be able to do this...
I account this one of those areas where the people who know how to do it, also have some hope of knowing better than to.
Why? Even ignoring the abuse possibilities, what possible reason could we have for that time and effort investment when those problems are already far more competently and easily handled than we ever could, and there are so many other, more rewarding and demanding problems and features on the burner?
We all know CGI is sub-optimal. We're also planning to stop vending archives directly from disk, increasing the CGI load.
True, however the processing delta can be kept quite small.
mod_python or a web runner would perform better.
The problem there is that they are insufficiently portable.
I feel the reverse-proxy configuration (similar to zope) would be the better choice.
Why would it be better? What are the disadvantages of those benefits? What specifically useful or necessary function would it add which is not being served today? What interesting and valuable deployment cases would it prevent or make more difficult? Which would it open to the product that are not current addressed?
Let's get a cost and value statement going.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On Friday 31 October 2003 20:17, J C Lawrence wrote:
Right, but the information lost across the non-SMTP translation is irretrievable and necessary.
sorry, I don't get it. Right now we're receiving messages over a pipe and as far as I see we're not using any environment or command line parameter (beside the script name) so where's this SMTP magic? Fetchmail would pass exactly the same bytestream over the same pipe, or do I miss something?
We all know CGI is sub-optimal. We're also planning to stop vending archives directly from disk, increasing the CGI load.
True, however the processing delta can be kept quite small.
This is not only a CPU load problem... this is also a lock contention (over the list configuration) problem.
mod_python or a web runner would perform better.
The problem there is that they are insufficiently portable.
I already explained how this can be solved for a web runner, please argument on that proposal.
I feel the reverse-proxy configuration (similar to zope) would be the better choice.
Why would it be better?
first of all we absolutely need to avoid the CGI to load, modify and save the list config. There's a big lock contention and it's a PITA to code. This would be true even for a transactional berkeley DB or similar setup. Remember that we want to configure and administer TTW also the spam filter. Right now in a 200 subscribers list I have: [pioppo@liston flug]$ ll *.pck -rw-rw---- 1 mailman mailman 56639 Oct 31 19:59 config.pck -rw-r--r-- 1 mailman mailman 378634 Oct 31 19:59 spam.pck Can we afford to re-load such a beast for each HTTP request on a list with one million users and/or some megabytes of spam data?
Then we get a cleaner code (we won't have m.Load() and m.Save() scattered all over the map)
Finally, we completely avoid the SGID driver.
What are the disadvantages of those benefits?
I see none.
What specifically useful or necessary function would it add which is not being served today?
we'll be able to centralize the configuration data all in one place (instead of one .pck per list, which we're pretty much forced now due to the CGI reload .pck everytime). This is good:
- to move toward a user-centric Mailman
- to easy system administration (backups, etc.)
- to build a site-admin web panel
Furthermore, Mailman could run on a different machine, not the one running the web server.
What interesting and valuable deployment cases would it prevent or make more difficult?
On a web server without support for reverse proxy rules, one will need to configure and activate the glue CGI. It shouldn't be more difficult than it is now (we already have a glue CGI).
I know, this CGI could talk with the running Mailman using something different from HTTP, so we could do everything I described without a built-in HTTP server. We could use a some-different-protocol server, but do you know a better protocol?
Which would it open to the product that are not current addressed?
sorry?
-- Adde parvum parvo magnus acervus erit -- Ovidio
At 10:04 PM +0100 2003/10/31, Simone Piunno wrote:
Right now we're receiving messages over a pipe and as far as I see we're not using any environment or command line parameter (beside the script name) so where's this SMTP magic?
You mean the envelope sender address? The IP address of the envelope sender?
Fetchmail would pass exactly the same bytestream over the same pipe, or do I miss something?
Yup. Fetchmail loses exactly the same information, in exactly the same way. As soon as the message is written to a mailbox somewhere, you lose the envelope information. So, retrieving the mailbox via POP3 doesn't work.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Friday 31 October 2003 22:30, Brad Knowles wrote:
Right now we're receiving messages over a pipe and as far as I see we're not using any environment or command line parameter (beside the script name) so where's this SMTP magic?
You mean the envelope sender address? The IP address of the envelope sender?
yes, I mean exactly this, we're not retrieving them, neither by command line options nor by environment variables. Doing it would probably be MTA-specific (i.e. less portable).
I want also to point you to the USE_ENVELOPE_SENDER parameter in Defaults.py and to the get_sender method in Mailman/Message.py, where this parameter is only used to decide in which priority order we read "From:" and "Sender:" from the message header.
Yup. Fetchmail loses exactly the same information, in exactly the same way. As soon as the message is written to a mailbox somewhere, you lose the envelope information. So, retrieving the mailbox via POP3 doesn't work.
I perfectly know what you mean, the fact is that over the pipe we get exactly a mailbox format (but without the leading "From " line) so according to you Mailman 2.1 doesn't work either! What are you trying to demonstrate?
-- Adde parvum parvo magnus acervus erit -- Ovidio
participants (3)
-
Brad Knowles -
J C Lawrence -
Simone Piunno