Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA writes:

Spamming would be the case when you are sending the emails to people who don't want to receive such emails. While if we control the <email> variable to take value from the set of emails of the list members only and not allowing the use of template variables i.e < .. > stuff in the *To: *field.

Ah, but Mailman is a winning application because it's easy to add and remove subscribers. You can already upload files in the "mass add" screen of subscription management. If you're going to work on Mailman, remember the first rule of mail abuse:

RULE #1: All mail programs can be used to spam.

That said, I'm pretty sure people are already using Mailman for spamming in exactly that way (uploading files of target addresses), and there are some features like headers and footers that could be adapted to "personalized" spam. I don't see why the good guys should be prevented from using features that the bad guys have anyway. So I don't consider the smells like spam, tastes like spam, argument prohibitive (although I sympathize with Terri).

...

...

And I have a spreadsheet data on the mailing list server like this: https://docs.google.com/spreadsheets/d/1cAbdSmc1NA-C9IZFjc_ zB67qEvgmX8Jr3xYyGxPdwdU/pubhtml

Mailman can have a functionality of flooding the /template/ by using the spreadsheet data. The variables in the /template/ (< -- > stuff) would be replaced by the corresponding row data in the spreadsheet corresponding to the emails of the list members. This can provide great flexibility to mailman users who use mailman as announcement list.

To be honest, this application would not be very high on my list of interesting projects. In the business application you described, I would be just as happy sending the table of assignments to everybody (and if there are assigned time slots, it doubles as the program).

On the other hand, for marketing mail shots I would typically want a more flexible program. For example, if a customer has children and I know their names, then I would insert a whole paragraph about them, including their names, and probably the text would depend on gender and hobbies and so on. Or consider a cellphone service, the customer might be a family with several members and phones, and your letter probably should treat each member appropriately recommending upgrades according to usage patterns and demographics. That doesn't fit well into the rectangular spreadsheet model of row per message.

I think that perhaps a more general database that *can* read spreadsheets but is not limited to that model would be more appropriate. But that is likely to be a fairly big project unless you're quite familiar with this kind of object-oriented database.

Regards,