On Tuesday 04 June 2002 05:07 pm, Doug La Farge wrote: > Because the user of this list needs to be able to send from their > Outlook Express client with all the fancy images and formatting. > It's a bit of a tedious job to "migrate" the email produced in > Outlook containing all those either local or remote images to a web > form or text file. Currently I have functionality that allows the > Admin to send their newsletter via a web form interface but here > again it's tough to get the images and formatting "just right". I'm > certainly open to suggestions on other ways of doing this but it > needs to be "dumbed-down" to users that only understand Outlook > Express. Know what I mean? :-\
Perhaps you are working very hard to solve the wrong problem. If the users truly need to fill out a web form, wouldn't it be easier to maintain that form on the web site, and send a URL for the users to click? Practically all GUI- based email clients now support clicking on URLs embedded even in plain-text messages. How many people receive this mailing? If you can reduce it down to plain text with a link, or even a simple MIME message of Content-type: text/html, you will greatly reduce the amount of bytes your MTA must handle and you will improve performance. What you are proposing to do also will not work for recipients who have HTML email turned off, as quite a few people do for reasons of security or privacy. If your users are nontechnical, putting the handling of the web forms totally on the server allows you to give them much better direct support, allows you to more easily leverage your previous work (I get the impression that there are differences with every issue but also some fundamental similarities from one to the next), and is compatible with a much larger variety of email clients. It also allows you to make revisions and correct mistakes in the form even after the emails are being sent. I'm not trying to knock the application itself, but you asked for alternative approaches and I'm suggesting one. Why try to turn an email program into a web browser when users have a perfectly good browser already, and even the most illiterate user can understand how to click on a link in a text message? If you really must send out web forms, consider using the Perl, PHP, or Java libraries that can generate multipart MIME messages, and then feeding the output to a standard SMTP library function using the algorithm suggested by another member of this list (basically a database row iteration). I agree with the other poster -- if you are disabling all the subscribe/unsubscribe and web-based features of Mailman, and using it only as a mass mailer, you are not using 90% of its capabilities, and there are much better ways to accomplish what you need, with less overhead and less complexity. Perhaps if you could give us a better idea of the specifics of the application, with particular regard to the form itself, as well as the size and nature of the intended subscription base, we could offer further suggestions that are more targeted to your needs. Nonetheless, I hope that one or more of the ideas I've suggested above might be of benefit, perhaps triggering further ideas of your own. Kind regards, Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them [EMAIL PROTECTED] | having a bad operating system." -- Linus Torvalds http://www.4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) ------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
