hello, first off, the concepts behind librelist and lamson are great; i've been following them for some time now. anyways, im trying to use librelist to handle super low traffic git repository updates. my project: http://github.com/extofme/aur-pyjs can be configured to email only a single address, ie. the list. however... i don't know how to subscribe the github email, since i don't control it and it's automated. can i manually subscribe an email address to my list (aur.pyjs)? thanks, C Anthony
On Wed, Jun 30, 2010 at 2:01 PM, C Anthony Risinger <anthony@extof.me> wrote: > hello, > > first off, the concepts behind librelist and lamson are great; i've > been following them for some time now. > > anyways, im trying to use librelist to handle super low traffic git > repository updates. my project: > > http://github.com/extofme/aur-pyjs > > can be configured to email only a single address, ie. the list. > however... i don't know how to subscribe the github email, since i > don't control it and it's automated. > > can i manually subscribe an email address to my list (aur.pyjs)? what i really need is to allow: noreply@github.com to email the list, but not have them actually be subscribed, ie. don't send them anything. is this possible? thanks, C Anthony
i have had this issue as well. As far as I know, there is not solution. (But it would be a great feature) On Wed, Jun 30, 2010 at 3:09 PM, C Anthony Risinger <anthony@extof.me>wrote: > On Wed, Jun 30, 2010 at 2:01 PM, C Anthony Risinger <anthony@extof.me> > wrote: > > hello, > > > > first off, the concepts behind librelist and lamson are great; i've > > been following them for some time now. > > > > anyways, im trying to use librelist to handle super low traffic git > > repository updates. my project: > > > > http://github.com/extofme/aur-pyjs > > > > can be configured to email only a single address, ie. the list. > > however... i don't know how to subscribe the github email, since i > > don't control it and it's automated. > > > > can i manually subscribe an email address to my list (aur.pyjs)? > > what i really need is to allow: > > noreply@github.com > > to email the list, but not have them actually be subscribed, ie. don't > send them anything. > > is this possible? > > thanks, > C Anthony > -- Sebastian Benthall OpenGeo - http://opengeo.org
On Wed, Jun 30, 2010 at 03:50:33PM -0400, Sebastian Benthall wrote: > i have had this issue as well. As far as I know, there is not solution. > (But it would be a great feature) Yeah, it's kind of outside the scope of librelist. If I started trying to handle all the different possible services out there that do this, then I'd constantly be updating for each new one and all the various ways they'd want this. Really, it's no you guys that I'd have to work with, it's people like github. In the past, it's been on the service to implement this. If github wants to support librelist, then it's much easier for them to recognize librelist and send out a short reply to any confirmations. I believe a few services have done this for people. -- Zed A. Shaw http://zedshaw.com/
I agree with Zed. It makes more sense for other services to add support for librelist once than Zed having to add support for other services again and again. On 7/1/10, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Wed, Jun 30, 2010 at 03:50:33PM -0400, Sebastian Benthall wrote: >> i have had this issue as well. As far as I know, there is not solution. >> (But it would be a great feature) > > Yeah, it's kind of outside the scope of librelist. If I started trying > to handle all the different possible services out there that do this, > then I'd constantly be updating for each new one and all the various > ways they'd want this. Really, it's no you guys that I'd have to work > with, it's people like github. > > In the past, it's been on the service to implement this. If github > wants to support librelist, then it's much easier for them to recognize > librelist and send out a short reply to any confirmations. I believe a > few services have done this for people. > > > -- > Zed A. Shaw > http://zedshaw.com/ > -- Sent from my mobile device
On Wed, Jun 30, 2010 at 4:04 PM, Mir Nazim <mn@mirnazim.org> wrote: > I agree with Zed. It makes more sense for other services to add > support for librelist once than Zed having to add support for other > services again and again. > > On 7/1/10, Zed A. Shaw <zedshaw@zedshaw.com> wrote: >> On Wed, Jun 30, 2010 at 03:50:33PM -0400, Sebastian Benthall wrote: >>> i have had this issue as well. As far as I know, there is not solution. >>> (But it would be a great feature) >> >> Yeah, it's kind of outside the scope of librelist. If I started trying >> to handle all the different possible services out there that do this, >> then I'd constantly be updating for each new one and all the various >> ways they'd want this. Really, it's no you guys that I'd have to work >> with, it's people like github. >> >> In the past, it's been on the service to implement this. If github >> wants to support librelist, then it's much easier for them to recognize >> librelist and send out a short reply to any confirmations. I believe a >> few services have done this for people. perhaps, but it makes more sense to me to just give me the ability to add the email myself; problem solved for any service. a little bit of admin features wouldn't hurt, right? C Anthony
On Wed, Jun 30, 2010 at 04:08:08PM -0500, C Anthony Risinger wrote: > perhaps, but it makes more sense to me to just give me the ability to > add the email myself; problem solved for any service. > > a little bit of admin features wouldn't hurt, right? Well, think through this if you're a spammer. 1. Setup librelist account. 2. Subscribe 100,000 people without them knowing. 3. Send them viagra spam and request that they meet you at fedex to get their lottery winnings. 4. ... 5. Profit! It also violates the spirit of Librelist which is to create a communication system that nobody owns so that everyone can trust that their contributions will be heard. This gives your project some trustworthiness since people know that you're playing fair. In other projects, like say Python, they have secret lists, backroom deals, off-list conversations, and everyone outside of the "in crowd" knows they're second class citizens. If I let one person get a bit of admin, then they'll use it to work out their self-esteem issues on everyone else. :-) -- Zed A. Shaw http://zedshaw.com/
On Thu, Jul 1, 2010 at 6:36 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Wed, Jun 30, 2010 at 04:08:08PM -0500, C Anthony Risinger wrote: >> perhaps, but it makes more sense to me to just give me the ability to >> add the email myself; problem solved for any service. >> >> a little bit of admin features wouldn't hurt, right? > > Well, think through this if you're a spammer. > > 1. Setup librelist account. > 2. Subscribe 100,000 people without them knowing. > 3. Send them viagra spam and request that they meet you at fedex to get > their lottery winnings. > 4. ... > 5. Profit! > > It also violates the spirit of Librelist which is to create a > communication system that nobody owns so that everyone can trust that > their contributions will be heard. This gives your project some > trustworthiness since people know that you're playing fair. In other > projects, like say Python, they have secret lists, backroom deals, > off-list conversations, and everyone outside of the "in crowd" knows > they're second class citizens. > > If I let one person get a bit of admin, then they'll use it to work out > their self-esteem issues on everyone else. :-) The last sentence is awesome and 100% true. :-D Moreover, if it is a community list, I do not understand why would anyone want to play big daddy on it and impose stuff on others. PS: Some cases might require features like kicking/banning a subscriber(trolls, noise makers and human spammers). I guess that might work by initiating an email based voting. A process may look something like: 1. send an email to vote2ban-<subscriber>-<listname>@librelist.com 2. everyone responds with +1 or -1. 3. librelist takes action based on number of votes in favor after everyone has replied or say 1 week (which ever is earlier) and Just a thought, with full understanding of the fact that we are getting librelist for free and Zed also has other important things to do with his time. > > -- > Zed A. Shaw > http://zedshaw.com/ >
On Thu, Jul 1, 2010 at 3:25 AM, Mir Nazim <mn@mirnazim.org> wrote: > On Thu, Jul 1, 2010 at 6:36 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: >> On Wed, Jun 30, 2010 at 04:08:08PM -0500, C Anthony Risinger wrote: >>> perhaps, but it makes more sense to me to just give me the ability to >>> add the email myself; problem solved for any service. >>> >>> a little bit of admin features wouldn't hurt, right? >> >> Well, think through this if you're a spammer. >> >> 1. Setup librelist account. >> 2. Subscribe 100,000 people without them knowing. >> 3. Send them viagra spam and request that they meet you at fedex to get >> their lottery winnings. >> 4. ... >> 5. Profit! >> >> It also violates the spirit of Librelist which is to create a >> communication system that nobody owns so that everyone can trust that >> their contributions will be heard. This gives your project some >> trustworthiness since people know that you're playing fair. In other >> projects, like say Python, they have secret lists, backroom deals, >> off-list conversations, and everyone outside of the "in crowd" knows >> they're second class citizens. >> >> If I let one person get a bit of admin, then they'll use it to work out >> their self-esteem issues on everyone else. :-) > > The last sentence is awesome and 100% true. :-D > Moreover, if it is a community list, I do not understand why would > anyone want to play big daddy on it and impose stuff on others. > > PS: Some cases might require features like kicking/banning a > subscriber(trolls, noise makers and human spammers). I guess that > might work by initiating an email based voting. A process may look > something like: > > 1. send an email to vote2ban-<subscriber>-<listname>@librelist.com > 2. everyone responds with +1 or -1. > 3. librelist takes action based on number of votes in favor after > everyone has replied or say 1 week (which ever is earlier) and > > Just a thought, with full understanding of the fact that we are > getting librelist for free and Zed also has other important things to > do with his time. heh, you beat me to this. i was going to suggest that admin features could be implemented, but admins must be "elected" by regular users of the list, or anything that happens must be accepted by 50%+ of the lists "real" members, and there aren't any admins. i say "real users" because in my case, the github user would be an automated send-only account on the list, and shouldn't be included in votes. something like: ------------------------------------------------------ -----| request... To: aur.pyjs-admin@librelist.com From: me@myself.com Subject: <None> <None> -----| response... To: me@myself.com From: aur.pyjs-admin-session-123456789abcdefg@librelist.com Subject: Administrative options You have requested a list of available administrative options for list aur.pyjs: QUERY 1) member list 2) admin list 3) pending proposals (anything you or other users have initiated [votes/nominations/etc.]) EDIT 4) nominate a member for admin privileges ADD 5) nominate a non-member for send-only status 6) nominate a non-member for receive-only status 7) nominate a non-member for member status REMOVE 8) impeach an admin 9) exile a member 10) discontinue this list Please respond with your choice. -----| request... To: aur.pyjs-admin-session-123456789abcdefg@librelist.com From: me@myself.com Subject: Re: Administrative options 5 noreply@github.com -----| response... To: me@myself.com From: aur.pyjs-admin-session-123456789abcdefg@librelist.com Subject: Re: Administrative options You have requested that noreply@github.com be added as a send-only user. As you are the only member of this list, your request has been auto-approved. ------------------------------------------------------ since everything that happens must be approved by real members, spammers could not authenticate any new users, because it would require the permission of the (1 or 2) users they are already spamming. they would only be able to auto-add two users, after that, one of those users would have to agree; unlikely. this would also allow everyone to remove lists on their own, and add automated users. it would be a little work, but i implemented something similar to this at my previous job: clients could email a service, and get a list of options. they could then perform searches or edit their information by talking to an email bot. worked pretty good, and wasn't all that difficult to implement. just some thoughts; might be a cool way to take the "we are all equal on this list" concept to the next level. C Anthony
On Fri, Jul 2, 2010 at 5:24 AM, C Anthony Risinger <anthony@extof.me> wrote: > On Thu, Jul 1, 2010 at 3:25 AM, Mir Nazim <mn@mirnazim.org> wrote: >> On Thu, Jul 1, 2010 at 6:36 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: >>> On Wed, Jun 30, 2010 at 04:08:08PM -0500, C Anthony Risinger wrote: >>>> perhaps, but it makes more sense to me to just give me the ability to >>>> add the email myself; problem solved for any service. >>>> >>>> a little bit of admin features wouldn't hurt, right? >>> >>> Well, think through this if you're a spammer. >>> >>> 1. Setup librelist account. >>> 2. Subscribe 100,000 people without them knowing. >>> 3. Send them viagra spam and request that they meet you at fedex to get >>> their lottery winnings. >>> 4. ... >>> 5. Profit! >>> >>> It also violates the spirit of Librelist which is to create a >>> communication system that nobody owns so that everyone can trust that >>> their contributions will be heard. This gives your project some >>> trustworthiness since people know that you're playing fair. In other >>> projects, like say Python, they have secret lists, backroom deals, >>> off-list conversations, and everyone outside of the "in crowd" knows >>> they're second class citizens. >>> >>> If I let one person get a bit of admin, then they'll use it to work out >>> their self-esteem issues on everyone else. :-) >> >> The last sentence is awesome and 100% true. :-D >> Moreover, if it is a community list, I do not understand why would >> anyone want to play big daddy on it and impose stuff on others. >> >> PS: Some cases might require features like kicking/banning a >> subscriber(trolls, noise makers and human spammers). I guess that >> might work by initiating an email based voting. A process may look >> something like: >> >> 1. send an email to vote2ban-<subscriber>-<listname>@librelist.com >> 2. everyone responds with +1 or -1. >> 3. librelist takes action based on number of votes in favor after >> everyone has replied or say 1 week (which ever is earlier) and >> >> Just a thought, with full understanding of the fact that we are >> getting librelist for free and Zed also has other important things to >> do with his time. > > heh, you beat me to this. i was going to suggest that admin features > could be implemented, but admins must be "elected" by regular users of > the list, or anything that happens must be accepted by 50%+ of the > lists "real" members, and there aren't any admins. i say "real users" > because in my case, the github user would be an automated send-only > account on the list, and shouldn't be included in votes. > > something like: > > ------------------------------------------------------ > > -----| request... > > To: aur.pyjs-admin@librelist.com > From: me@myself.com > Subject: <None> > > <None> > > -----| response... > > To: me@myself.com > From: aur.pyjs-admin-session-123456789abcdefg@librelist.com > Subject: Administrative options > > You have requested a list of available administrative options for list aur.pyjs: > > QUERY > 1) member list > 2) admin list > 3) pending proposals (anything you or other users have initiated > [votes/nominations/etc.]) > EDIT > 4) nominate a member for admin privileges > ADD > 5) nominate a non-member for send-only status > 6) nominate a non-member for receive-only status > 7) nominate a non-member for member status > REMOVE > 8) impeach an admin > 9) exile a member > 10) discontinue this list > > Please respond with your choice. > > -----| request... > > To: aur.pyjs-admin-session-123456789abcdefg@librelist.com > From: me@myself.com > Subject: Re: Administrative options > > 5 noreply@github.com > > -----| response... > > To: me@myself.com > From: aur.pyjs-admin-session-123456789abcdefg@librelist.com > Subject: Re: Administrative options > > You have requested that noreply@github.com be added as a send-only > user. As you are the only member of this list, your request has been > auto-approved. > > ------------------------------------------------------ > > since everything that happens must be approved by real members, > spammers could not authenticate any new users, because it would > require the permission of the (1 or 2) users they are already > spamming. they would only be able to auto-add two users, after that, > one of those users would have to agree; unlikely. > > this would also allow everyone to remove lists on their own, and add > automated users. > > it would be a little work, but i implemented something similar to this > at my previous job: clients could email a service, and get a list of > options. they could then perform searches or edit their information > by talking to an email bot. worked pretty good, and wasn't all that > difficult to implement. just some thoughts; might be a cool way to > take the "we are all equal on this list" concept to the next level. > > C Anthony > Nice idea. I do not know much about how lamson works but based on my skimming through the lamson website, I think there is an extreme amount of flexibility and it can allow implementing almost any feature around emails.
On Fri, Jul 02, 2010 at 02:15:10PM +0530, Mir Nazim wrote: > Nice idea. > > I do not know much about how lamson works but based on my skimming > through the lamson website, I think there is an extreme amount of > flexibility and it can allow implementing almost any feature around > emails. Yep, generally that's true. -- Zed A. Shaw http://zedshaw.com/
On Wed, Jun 30, 2010 at 3:17 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Wed, Jun 30, 2010 at 03:50:33PM -0400, Sebastian Benthall wrote: >> i have had this issue as well. As far as I know, there is not solution. >> (But it would be a great feature) > > Yeah, it's kind of outside the scope of librelist. If I started trying > to handle all the different possible services out there that do this, > then I'd constantly be updating for each new one and all the various > ways they'd want this. Really, it's no you guys that I'd have to work > with, it's people like github. > > In the past, it's been on the service to implement this. If github > wants to support librelist, then it's much easier for them to recognize > librelist and send out a short reply to any confirmations. I believe a > few services have done this for people. alright, ill take that as a no :-( i was going to request github enable librelist, but then i remembered that i use google apps for my domains, and google apps supports groups. so... i created a group email under my domain, added the github email, and bang; everything is working peachy :-D you can go ahead and remove my group (aur.pyjs), sorry about the noise. i thought librelist would work nicely, but pointing two automated systems at each other just wasn't going to fly. thanks, C Anthony
On Wed, Jun 30, 2010 at 03:49:40PM -0500, C Anthony Risinger wrote: > so... i created a group email under my domain, added the github email, > and bang; everything is working peachy :-D Yep, if you need more control then you're better off with something else. Librelist is mostly for the projects where the majority of the usage is just people talking, nothing more. -- Zed A. Shaw http://zedshaw.com/
The 1st problem is that github is using a noreply address. They should be allowing us to set the reply address. That's an issue that lies squarely with Github and I wish they would fix it. The 2nd problem is that librelist allows us no way to subscribe 3rd-party addresses. That may be a philosophical choice by Zed, and I can understand it. On the other hand, expecting the 3rd-party to build us a request-confirm handler for these (fairly rare) use-cases is not likely to be high on thier priority list. I think a good compromise position is to have librelist allow a 3rd party subscription request, via some special notation. Libralist already has the confirm process, it would only need to route the confirmation to the 3rd-party's email instead of the original senders.
On Wed, Jun 30, 2010 at 05:09:46PM -0400, Trans wrote: > I think a good compromise position is to have librelist allow a 3rd > party subscription request, via some special notation. Libralist > already has the confirm process, it would only need to route the > confirmation to the 3rd-party's email instead of the original senders. Isn't going to work. The problem isn't 3rd party emails, the problem is that 3rd party won't confirm the subscription. You could subscribe someone right now with a bit of code if you wanted, but they'd have to confirm it. Without this confirmation, you get people making spam lists or subscribing people against their will. If the 3rd party address is a "send only" address, then people can subscribe trolls who can blast away without having to read the responses. It also subscribes bots that expect to be talking to one person, so they aren't designed for this use case. It can also confuse people who maybe get subscribed this way and wonder why they're not getting emails. It also makes it hard on the server because now I'm having to separate "send/recv" vs. "send only" addresses and how do you manage that? If the 3rd party address is both send/recv then that violates the rule that everyone must opt-in. While in this narrow context it seems fine, it's *much* too easy to abuse being able to subscribe someone else. No, the only solution is that the target address needs to confirm, or just don't use librelist. -- Zed A. Shaw http://zedshaw.com/
On Wed, Jun 30, 2010 at 8:56 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Wed, Jun 30, 2010 at 05:09:46PM -0400, Trans wrote: >> I think a good compromise position is to have librelist allow a 3rd >> party subscription request, via some special notation. Libralist >> already has the confirm process, it would only need to route the >> confirmation to the 3rd-party's email instead of the original senders. > > Isn't going to work. The problem isn't 3rd party emails, the problem is > that 3rd party won't confirm the subscription. You could subscribe > someone right now with a bit of code if you wanted, but they'd have to > confirm it. Without this confirmation, you get people making spam lists > or subscribing people against their will. > > If the 3rd party address is a "send only" address, then people can > subscribe trolls who can blast away without having to read the > responses. It also subscribes bots that expect to be talking to one > person, so they aren't designed for this use case. It can also confuse > people who maybe get subscribed this way and wonder why they're not > getting emails. It also makes it hard on the server because now I'm > having to separate "send/recv" vs. "send only" addresses and how do you > manage that? > > If the 3rd party address is both send/recv then that violates the rule > that everyone must opt-in. While in this narrow context it seems fine, > it's *much* too easy to abuse being able to subscribe someone else. > > No, the only solution is that the target address needs to confirm, or > just don't use librelist. Yes, I do not mean to avoid confirmation. I would still expect it to confirm. I just mean that librelist would respect the reply-to address. So If github allowed us to set the reply-to address then they could send out an automated message which would be confirmed via the reply-to address.
On Thu, Jul 01, 2010 at 08:31:25AM -0400, Trans wrote: > Yes, I do not mean to avoid confirmation. I would still expect it to > confirm. I just mean that librelist would respect the reply-to > address. So If github allowed us to set the reply-to address then they > could send out an automated message which would be confirmed via the > reply-to address. Hmmmmm, now that's an idea. Can you think up a ticket for this and put it into the tracker? http://support.librelist.com It could just be considered a generic bug actually. -- Zed A. Shaw http://zedshaw.com/
On Wed, Jun 30, 2010 at 4:09 PM, Trans <transfire@gmail.com> wrote: > The 1st problem is that github is using a noreply address. They should > be allowing us to set the reply address. That's an issue that lies > squarely with Github and I wish they would fix it. > > The 2nd problem is that librelist allows us no way to subscribe > 3rd-party addresses. That may be a philosophical choice by Zed, and I > can understand it. On the other hand, expecting the 3rd-party to build > us a request-confirm handler for these (fairly rare) use-cases is not > likely to be high on thier priority list. > > I think a good compromise position is to have librelist allow a 3rd > party subscription request, via some special notation. Libralist > already has the confirm process, it would only need to route the > confirmation to the 3rd-party's email instead of the original senders. that seems legitimate. so, in github i would set the email to, say: aur.pyjs-altconfirm-anthony.at.extof.me@librelist.com trigger a test email, which would send an auth request to me, then after authenticating, change the email in github back to: aur.pyjs@librelist.com something like that? are there any glaring vulnerabilities to this approach? C Anthony
On Wed, Jun 30, 2010 at 04:16:32PM -0500, C Anthony Risinger wrote: > that seems legitimate. so, in github i would set the email to, say: > > aur.pyjs-altconfirm-anthony.at.extof.me@librelist.com > > trigger a test email, which would send an auth request to me, then > after authenticating, change the email in github back to: > > aur.pyjs@librelist.com > > something like that? are there any glaring vulnerabilities to this approach? That's another possibility. You really just need a way to see what the confirm address is and then send an email at it. In most mail clients it's a 10 second setting to fake out your email address (as Dustin Curits found out recently :-) -- Zed A. Shaw http://zedshaw.com/
On Wed, Jun 30, 2010 at 4:17 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Wed, Jun 30, 2010 at 03:50:33PM -0400, Sebastian Benthall wrote: > > i have had this issue as well. As far as I know, there is not solution. > > (But it would be a great feature) > > Yeah, it's kind of outside the scope of librelist. If I started trying > to handle all the different possible services out there that do this, > then I'd constantly be updating for each new one and all the various > ways they'd want this. Really, it's no you guys that I'd have to work > with, it's people like github. > > In the past, it's been on the service to implement this. If github > wants to support librelist, then it's much easier for them to recognize > librelist and send out a short reply to any confirmations. I believe a > few services have done this for people. > > > -- > Zed A. Shaw > http://zedshaw.com/ > Does that mean that more or less any email-based list administration is out of scope for librelist? -- Sebastian Benthall OpenGeo - http://opengeo.org
On Wed, Jun 30, 2010 at 04:46:46PM -0400, Sebastian Benthall wrote: > On Wed, Jun 30, 2010 at 4:17 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > Does that mean that more or less any email-based list administration is out > of scope for librelist? For now, yeah. It runs well and nobody seems to need them really. If they do they go ahead and setup their own thing. If I get time I may fix up a few annoying things, but otherwise, keeping it lo-fi makes it work for 80% of the projects out there. -- Zed A. Shaw http://zedshaw.com/
On Wed, Jun 30, 2010 at 8:49 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Wed, Jun 30, 2010 at 04:46:46PM -0400, Sebastian Benthall wrote: > > On Wed, Jun 30, 2010 at 4:17 PM, Zed A. Shaw <zedshaw@zedshaw.com> > wrote: > > Does that mean that more or less any email-based list administration is > out > > of scope for librelist? > > For now, yeah. It runs well and nobody seems to need them really. If > they do they go ahead and setup their own thing. If I get time I may > fix up a few annoying things, but otherwise, keeping it lo-fi makes it > work for 80% of the projects out there. > > -- > Zed A. Shaw > http://zedshaw.com/ > Makes sense. Thanks for clarifying (I've wonder about the sort of thing discussed on this thread a lot), and thanks for the great software/service. -- Sebastian Benthall OpenGeo - http://opengeo.org
On Wed, Jun 30, 2010 at 2:50 PM, Sebastian Benthall <seb@opengeo.org> wrote: > i have had this issue as well. As far as I know, there is not solution. > (But it would be a great feature) > > On Wed, Jun 30, 2010 at 3:09 PM, C Anthony Risinger <anthony@extof.me> > wrote: >> >> On Wed, Jun 30, 2010 at 2:01 PM, C Anthony Risinger <anthony@extof.me> >> wrote: >> > hello, >> > >> > first off, the concepts behind librelist and lamson are great; i've >> > been following them for some time now. >> > >> > anyways, im trying to use librelist to handle super low traffic git >> > repository updates. my project: >> > >> > http://github.com/extofme/aur-pyjs >> > >> > can be configured to email only a single address, ie. the list. >> > however... i don't know how to subscribe the github email, since i >> > don't control it and it's automated. >> > >> > can i manually subscribe an email address to my list (aur.pyjs)? >> >> what i really need is to allow: >> >> noreply@github.com >> >> to email the list, but not have them actually be subscribed, ie. don't >> send them anything. >> >> is this possible? that's too bad :-( isn't there a way to administrate a list? i've known about librelist for awhile, but i haven't had a use for it until now. Zed, anyway you could manually add noreply@github.com to my list (aur.pyjs)? if there is no way around it, they can just be added to the list like normal users... they will just drop the emails anyway. possible? else i guess ill have to try a google group or something :-( thanks, C Anthony