On Fri, 31 Oct 2003 00:45:32 +0100 Simone Piunno <pioppo@ferrara.linux.it> wrote:
On Thursday 30 October 2003 05:17, J C Lawrence wrote:
...as well as implement a bulk mailer to eliminate the need for an outgoing mail server.
Eeeek! I trust this would be for immediate handoff to a "real" MTA versus handling final delivery directly? Quite the Pandora's box if not.
I believe the best approach is to cover all options:
No. This is an one-size-doesn't-fit-anybody argument.
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.
... (polling! I can hear you scream while you read this!) and send them directly to the internet (no real MTA involved) and will probably serve web pages directly, controlling port 80 (no real web server involved).
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?
--
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.
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 :)
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. 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... BTW we already use lynx for html->text conversion, and we already
prepare aliases and virtual for postfix, so we could also make Mailman able
to generate a fetchmail.conf file.
I'm not asking to make really heavy hacks like using a single email address to
carry all the incoming traffic (-bounce, -join, -leave and so on). Nowadays
many people have mailboxes gathering all the traffic for many addresses, and
it's very common for people to have web access to the configuration of all
the mailboxes for a domain they own but, is managed on a 3rd party mail
server they can't install Mailman.
serve web pages directly, controlling port 80 (no real web server involved).
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. mod_python or a web runner
would perform better.
I feel the reverse-proxy configuration (similar to zope) would be the better
choice. And yes, I know that there are web servers unable to proxy requests
on a backend server, but this is easily solved by a small CGI just proxying
requests (we already do something very similar for incoming email, even if we
do it for different reasons - e.g. to use SGID for security)
So *if* we accept this solution, we already have an HTTP interface and we get
direct HTTP (for tests) for free. Whenever you have a problem in the proxied
configuration, you absolutely want to make direct requests to the backend, at
least to determine where the problem is (in the web server or in Mailman
itself?).
-- This signature intentionally left blank
participants (2)
-
J C Lawrence -
Simone Piunno