You can front a list with TMDA, pointing TMDA at your list's subscriber base and a local whitelist. TMDA then passes all subscriber mails straight thru to the list, but mail from non-subscribers is held until confirmed (at which point you can whitelist or not).
The TMDA lists do this to decent effect.
Nice side effects:
No more problems with posters from non-subscribed addresses. They have a subscription to _GET_ mail and to define an allowed posting address. They can (trivially) define additional allowed posting addresses by just posting from them and confirming the post to get on the whitelist. You're now essentially back in the old days of the 1980s when we could safely run open lists.
Almost all SPAM disappears. They don't confirm.
Ditto viruses.
Well some viruses might learn confirming down the road, but none do now and the confirmation steps can be trivially changed.
-- 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.
J C Lawrence <claw@kanga.nu> writes:
No more problems with posters from non-subscribed addresses. They have a subscription to _GET_ mail and to define an allowed posting address. They can (trivially) define additional allowed posting addresses by just posting from them and confirming the post to get on the whitelist.
Yup. One thing I also do is share an auto-whitelist among all the lists on my server. So, if claw@kanga.nu confirms his post to tmda-users, he'll instantly be able to post to tmda-workers as well. This makes things even more transparent for the end-user, particularly at sites hosting many lists.
You're now essentially back in the old days of the 1980s when we could safely run open lists.
Once in a blue moon, a spammer will actually confirm his spam to a list, which then requires a bit of intervention to remove the address from the auto-whitelist, and blacklist it. But, you'll also now have a verifiable address to use to track him down and fry his ass <wink>.
However, this is rare. It hasn't happened on any of my lists in the five months since I implemented this setup.
-- (http://tmda.net/)
J C Lawrence <claw@kanga.nu> writes:
There are cases where I don't want this however, and its proving rather a bitch to make a non-shared whitelist hang off a shared configuration (in my case a shared procmail RC).
I haven't found this to be the case at all, but I'm also driving my setup with dot-qmail files which makes this sort of thing trivial.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> Yup. One thing I also do is share an auto-whitelist among
JRM> all the lists on my server. So, if claw@kanga.nu confirms
JRM> his post to tmda-users, he'll instantly be able to post to
JRM> tmda-workers as well. This makes things even more
JRM> transparent for the end-user, particularly at sites hosting
JRM> many lists.I agree this would be ideal, but I wouldn't do it for MM2.1. Certainly for MM3.0 when we have a federated user database, this makes perfect sense.
-Barry
barry@python.org (Barry A. Warsaw) writes:
I agree this would be ideal, but I wouldn't do it for MM2.1.
Why not? Just because it would involve more changes than are appropriate for a release in beta?
Certainly for MM3.0 when we have a federated user database, this makes perfect sense.
I'm not familiar with a ``federated user database''.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> barry@python.org (Barry A. Warsaw) writes:
>> I agree this would be ideal, but I wouldn't do it for MM2.1.
JRM> Why not? Just because it would involve more changes than are
JRM> appropriate for a release in beta?Yes, and because we currently have no database that's shared across mailing lists. Issues I don't want to think about include concurrent access to a shared database.
>> Certainly for MM3.0 when we have a federated user database,
>> this makes perfect sense.
JRM> I'm not familiar with a ``federated user database''.One user database shared by all mailing lists. This will be the primary focus of Mailman 3.0.
-Barry
barry@python.org (Barry A. Warsaw) writes:
Yes, and because we currently have no database that's shared across mailing lists. Issues I don't want to think about include concurrent access to a shared database.
This assumes all the functionality is built into MM, rather than hooking TMDA into MM. In the latter case, it wouldn't matter whether MM had the shared db, as the lookup would come from an external source.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
>> Yes, and because we currently have no database that's shared
>> across mailing lists. Issues I don't want to think about
>> include concurrent access to a shared database.
JRM> This assumes all the functionality is built into MM, rather
JRM> than hooking TMDA into MM. In the latter case, it wouldn't
JRM> matter whether MM had the shared db, as the lookup would come
JRM> from an external source.So if we /don't/ build the functionality into MM2.1 (as Chuq is so sensibly arguing :) is there anything we need to do to implement the whitelisting TMDA fronted MM that is being proposed here?
If so, let's talk about that. If not, maybe we're done. :)
-Barry
On 7/29/02 5:35 PM, "Barry A. Warsaw" <barry@python.org> wrote:
So if we /don't/ build the functionality into MM2.1 (as Chuq is so sensibly arguing :) is there anything we need to do to implement the whitelisting TMDA fronted MM that is being proposed here?
<kaf> <kaf> <readme> <kaf>
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table! -- Shrek
barry@python.org (Barry A. Warsaw) writes:
So if we /don't/ build the functionality into MM2.1 (as Chuq is so sensibly arguing :) is there anything we need to do to implement the whitelisting TMDA fronted MM that is being proposed here?
I think we just need documentation. I've only ever combined MM and TMDA under qmail, and it's quite easy. Given .qmail-list which posts to the list, you just need to edit and add the following to the top of the file:
|preline /usr/bin/tmda-filter
Then make a symlink from .qmail-list-confirm-default to .qmail-list.
A FAQ entry with this along with some configuration suggestions would satisfy that. Perhaps I'll do this tomorrow.
Non-qmail MTAs aren't as flexible, so perhaps JC can comment on his experiences?
In any case, I think the necessary changes (if any) would go into TMDA and not MM. So, perhaps you are done.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> In any case, I think the necessary changes (if any) would go
JRM> into TMDA and not MM. So, perhaps you are done.Sounds good. Also, I guess a TMDA Howto could be added. I should probably also include a link to any TMDA documentation on the subject, when I overhaul MM's documentation <wink>.
-Barry
On another note, the logical approach IMO is to build this functionality into Mailman, rather than having to attach TMDA to your Mailman installation. TMDA includes much more than is relevant for protecting a mailing list.
Mailman already includes most of the tools to make this work. TMDA's challenge system is no more complex than how Mailman verifies a new subscriber. Once you turned this feature on, Mailman would store unconfirmed incoming messages under qfiles/ somewhere, prompt for confirmation, and release the message to the list once the confirmation is returned.
I envision Mailman's web configuration interface making this very easy. A checkbox to toggle whether existing subscribers are allowed through, a textbox to enter explicitly blacklisted addresses, etc.
Gravy like the "auto-whitelist" feature could be stolen from TMDA (also a pure-Python, GPL'd app) if necessary.
I'd expect this to be no more than a few days work for someone intimately familiar with Mailman's source.
I don't know of any MLM with this functionality built-in, and it will virtually eliminate all spam. How's that for motivation? <wink>
-- (http://tmda.net/)
On 7/28/02 7:49 PM, "Jason R. Mastaler" <jason@mastaler.com> wrote:
On another note, the logical approach IMO is to build this functionality into Mailman,
Yup. And Barry's already made positive-sounding noises, but holding up release 2.1 to add this doesn't make sense. But making it a focus of 2.2 or 3.0 does. I think we need to finish 2.1, and then start the next round of enhancements. We don't want to get into "always another last featuer" mode.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
No! No! Dead girl, OFF the table! -- Shrek
Chuq Von Rospach <chuqui@plaidworks.com> writes:
holding up release 2.1 to add this doesn't make sense.
I didn't suggest that it did.
But making it a focus of 2.2 or 3.0 does. I think we need to finish 2.1, and then start the next round of enhancements.
Works for me.
-- (http://tmda.net/)
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> Yup. And Barry's already made positive-sounding noises, but
CVR> holding up release 2.1 to add this doesn't make sense. But
CVR> making it a focus of 2.2 or 3.0 does. I think we need to
CVR> finish 2.1, and then start the next round of enhancements. We
CVR> don't want to get into "always another last featuer" mode.You've nailed me completely Chuq. ;) Not good, I know, but this one seems soooo easy.
-Barry
J C Lawrence <claw@kanga.nu> writes:
Given that the TMDA python product carries almost all the needed payload, I wonder if a TMDA-plugin rooted in the TMDA product doesn't make more sense.
I'm comfortable with this as well, and don't mind making modifications to TMDA that would make this easier if that proves necessary.
Since Mailman is the larger and more complex of the two, this should probably be spearheaded by someone familiar with Mailman, rather than the other way around. I'll be happy to assist on the TMDA side.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> I envision Mailman's web configuration interface making this
JRM> very easy. A checkbox to toggle whether existing subscribers
JRM> are allowed through, a textbox to enter explicitly
JRM> blacklisted addresses, etc.I wouldn't change how postings from existing subscribers are handled. I think the most straightforward approach would be to simply use this as a way to seed the accept_these_nonmembers list, without admin intervention.
JRM> Gravy like the "auto-whitelist" feature could be stolen from
JRM> TMDA (also a pure-Python, GPL'd app) if necessary.
JRM> I'd expect this to be no more than a few days work for
JRM> someone intimately familiar with Mailman's source.Maybe a few hours. :)
JRM> I don't know of any MLM with this functionality built-in, and
JRM> it will virtually eliminate all spam. How's that for
JRM> motivation? <wink>I'm hooked, but then I'm a push over. -Barry
Very cool, thanks for starting the discussion on this JC.
I'm torn. On the one hand, we /are/ supposed to be in feature freeze and jeez, can I ever get this thing out the door? Well, I'm going to try hard to do so as soon as possible.
OTOH, this seems like such a useful and simple feature to add, it'd be almost a crime not to. What I would do is this:
If a post comes from a non-member, send a confirmation message to them. This would actually use most of the machinery already in place for confirmations.
If they confirm/reply, we'd add the address to the accept_these_nonmembers list and send all their held messages on through.
Here's a question though: what do we do if the default moderation bit for members is turned on? I don't want to get into a situation where a member's posting would get held, but a non-member posting would go through without some interaction from the list owner.
I guess if the default moderation bit is set, then we wouldn't send out the confirmation message, and non-member postings would have to be approved just like they are today.
-Barry
I am trying to migrate a yahoo email list to my mailman list. One feature of yahoo is to send a reminder to the list of the weekly event the list is based on. Is there a way to do this with mailman, do I have to write a script in php or python and cron it? will mailman except email from the server and send them to the list?
thanks for your time and responses.
Salvatore Iozzia accelerator Chain Reaction Web - Guaranteed Hosting http://chainreactionweb.com Toll Free 866-994-7737
----- Original Message ----- From: "Barry A. Warsaw" <barry@python.org> To: "J C Lawrence" <claw@kanga.nu> Cc: <mailman-developers@python.org> Sent: Monday, July 29, 2002 7:31 PM Subject: Re: [Mailman-Developers] Cute TMDA use
Very cool, thanks for starting the discussion on this JC.
I'm torn. On the one hand, we /are/ supposed to be in feature freeze and jeez, can I ever get this thing out the door? Well, I'm going to try hard to do so as soon as possible.
OTOH, this seems like such a useful and simple feature to add, it'd be almost a crime not to. What I would do is this:
If a post comes from a non-member, send a confirmation message to them. This would actually use most of the machinery already in place for confirmations.
If they confirm/reply, we'd add the address to the accept_these_nonmembers list and send all their held messages on through.
Here's a question though: what do we do if the default moderation bit for members is turned on? I don't want to get into a situation where a member's posting would get held, but a non-member posting would go through without some interaction from the list owner.
I guess if the default moderation bit is set, then we wouldn't send out the confirmation message, and non-member postings would have to be approved just like they are today.
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman-21/listinfo/mailman-developers
"SFI" == Salvatore F Iozzia <sal@chainreactionweb.com> writes:
SFI> I am trying to migrate a yahoo email list to my mailman
SFI> list. One feature of yahoo is to send a reminder to the list
SFI> of the weekly event the list is based on. Is there a way to
SFI> do this with mailman, do I have to write a script in php or
SFI> python and cron it? will mailman except email from the server
SFI> and send them to the list?You can always set up a cron job that crafts the message and calls bin/inject to get the message delivered. Mailman 2.1, of course.
-Barry
barry@python.org (Barry A. Warsaw) writes:
Very cool, thanks for starting the discussion on this JC.
This is a topic I brought up 6 months ago, but I guess I didn't speak loud enough <wink>.
http://mail.python.org/pipermail-21/mailman-developers/2002-January/010404.h...
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> barry@python.org (Barry A. Warsaw) writes:
>> Very cool, thanks for starting the discussion on this JC.
JRM> This is a topic I brought up 6 months ago, but I guess I
JRM> didn't speak loud enough <wink>.
JRM> http://mail.python.org/pipermail-21/mailman-developers/2002-January/010404.htmlAt the time, I don't think I realized the implications of what you were putting together. My bad. Still, it's darn cool! :)
-Barry
barry@python.org (Barry A. Warsaw) writes:
At the time, I don't think I realized the implications of what you were putting together. My bad. Still, it's darn cool! :)
Better late than never <wink>.
-- (http://tmda.net/)
On 7/29/02 4:31 PM, "Barry A. Warsaw" <barry@python.org> wrote:
I guess if the default moderation bit is set, then we wouldn't send out the confirmation message, and non-member postings would have to be approved just like they are today.
I would set things up so that they don't go into the moderation queue until they're confirmed, and then moderated as normal. The moderator stuff doesn't change, except that the moderator doesn't see them until the user confirms them. That closes the hole of the moderator having to deal with spam to the posting address. So basically, you put TMDA in front of the moderator, not replace the moderator in that case. The list is still moderated, just whitelisted THEN moderated.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> I guess if the default moderation bit is set, then we wouldn't
>> send out the confirmation message, and non-member postings
>> would have to be approved just like they are today.
CVR> I would set things up so that they don't go into the
CVR> moderation queue until they're confirmed, and then moderated
CVR> as normal. The moderator stuff doesn't change, except that
CVR> the moderator doesn't see them until the user confirms
CVR> them. That closes the hole of the moderator having to deal
CVR> with spam to the posting address. So basically, you put TMDA
CVR> in front of the moderator, not replace the moderator in that
CVR> case. The list is still moderated, just whitelisted THEN
CVR> moderated.Ah wait, I see what you're suggesting. A confirmed non-member wouldn't get added to accept_these_nonmembers, but their message would not show up in the admindb until they've confirmed.
The messages would be in a sort of limbo until them, with timeout/auto-discards if they don't confirm after a certain amount of time. Once they've confirmed, we'll do the normal non-member action (although it would make little sense to go through this rigamarole if we're simply discarding or rejecting non-member postings).
Maybe the admindb should have a button that would let them see all held message, including non-confirmed ones? Perhaps that's a YAGNI.
Have I got that right? I'll think on it and try to decide whether it's worth adding to 2.1 or not.
-Barry
On Mon, 29 Jul 2002 22:29:29 -0400 Barry A Warsaw <barry@python.org> wrote:
Maybe the admindb should have a button that would let them see all held message, including non-confirmed ones? Perhaps that's a YAGNI.
I'd certainly like and use such a feature.
--
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.
participants (5)
-
barry＠python.org -
Chuq Von Rospach -
J C Lawrence -
Jason R. Mastaler -
Salvatore F. Iozzia