September 2008 - Techlist

[Mickaboo Techlist] Anti-spam measures this afternoon
by AMuse 30 Sep '08

30 Sep '08

Hi all! I have implemented some new mailserver rules that should help cut down on SPAM. -excluding- the mailing lists, senders to mickaboo are prohibited from sending email to more than 3 addresses in a 60 second period. This should combat the SPAM which comes in to all the coordinator- emails at once, while allowing people to email pretty regularly. I've tested it over the last 30 minutes and it seems to be working OK. I'm going to a meeting at work but will be checking in in about an hour to make sure everything is normal. Mal: If $@#@$ hits the fan for some reason, you can log in as root and do: # mount /dev/sdb1 /backups # cp /backups/etc/postfix/main.cf /etc/postfix/main.cf # postfix -v reload # umount /backups That'll restore the server back to original condition.

1 0

[Mickaboo Techlist] I can't log into the OTRS
by Ailsa 26 Sep '08

26 Sep '08

I'm getting a "session ID invalid. Need user data" error message. ~ Ailsa

1 0

Re: [Mickaboo Techlist] [Fwd: OPT-OUT Request from Mickaboo.org]
by AMuse 17 Sep '08

17 Sep '08

Nope! We would just need one with ASM access - or I will set the opt-outs to go to mail(a)mickaboo.org so we an all process a few of them when we get time. Pamela Lee wrote: > Yay! Do we know who our current volunteer is for that stuff? - Pam > > --- On *Wed, 9/17/08, AMuse /<amuse(a)foofus.com>/* wrote: > > From: AMuse <amuse(a)foofus.com> > Subject: [Fwd: OPT-OUT Request from Mickaboo.org] > To: "Mal Raff (MIR Consulting)" <mir(a)mircon.com>, "The mickaboo > tech list" <techlist(a)mickaboo.org>, "Pamela Lee" <pambudgie(a)yahoo.com> > Date: Wednesday, September 17, 2008, 11:39 AM > > FYI, I ran a test of our opt-out script and here's what the email to us > should look like when someone visits that site. Note that it is VERY > clear about how to complete the request, for our data entry volunteer. > > -------- Original Message -------- > Subject: OPT-OUT Request from Mickaboo.org > Date: Wed, 17 Sep 2008 10:35:46 -0700 (PDT) > From: testing(a)example.com > To: amuse(a)foofus.com > > > > The ASM owner with the email address testing(a)example.com has elected to opt-out > of some communications in the future. > Please copy any flags with "SELECTED:" next to them and enter them > into the "Comments:" field of their ASM owner > record. > > Please do not email me solicitations > Please do not send me physical mailings SELECTED: > donotcontact=solicit:snailmail > Please do not solicit me at all in the future > Please do not email me for any reason > Please do not send me physical mail at all SELECTED: donotcontact=atall > > > > >

1 0

[Mickaboo Techlist] [Fwd: OPT-OUT Request from Mickaboo.org]
by AMuse 17 Sep '08

17 Sep '08

FYI, I ran a test of our opt-out script and here's what the email to us should look like when someone visits that site. Note that it is VERY clear about how to complete the request, for our data entry volunteer. -------- Original Message -------- Subject: OPT-OUT Request from Mickaboo.org Date: Wed, 17 Sep 2008 10:35:46 -0700 (PDT) From: testing(a)example.com To: amuse(a)foofus.com The ASM owner with the email address testing(a)example.com has elected to opt-out of some communications in the future. Please copy any flags with "SELECTED:" next to them and enter them into the "Comments:" field of their ASM owner record. Please do not email me solicitations Please do not send me physical mailings SELECTED: donotcontact=solicit:snailmail Please do not solicit me at all in the future Please do not email me for any reason Please do not send me physical mail at all SELECTED: donotcontact=atall

1 0

Re: [Mickaboo Techlist] newsletter opt-outs
by AMuse 16 Sep '08

16 Sep '08

For people wanting to opt-out of things, we don't send them any email address at all: We include this link in opt out pages. https://mickaboo.org/opt-out.html That script is what emails our OTRS queue and we have a volunteer do ASM data entry exactly as the script says to, so that next time we generate a list of emails to mail to, the opt out request is respected. In that manner we don't have to "erase" peoples' emails from ASM, we just don't include them in the lists. So, for example, if I enter an email address and click "Do not email me for any reason" then the script should email our OTRS queue and advise the volunteer to go into ASM, open their owner record and put "donotcontact=email" in their owner comments field. When we generate our mailing list the SQL query is along the lines of 'SELECT OwnerEmail FROM owner WHERE OwnerComments NOT LIKE "%donotcontact=email%";' Mal Raff wrote: > Hi: > > You have an 'opt-out(a)mickaboo.org' email alias set up pointing to > you. However, they are planning a mass email for the newsletter > that may generate a LOT of traffic. Diane (newsletter person) > has volunteered to handle the opt-outs. Should we create another > email alias specifically for the newsletter opt-outs to preserve > the more generic address? > > -m- >

1 0

Re: [Mickaboo Techlist] database
by AMuse 03 Sep '08

03 Sep '08

Mal Raff wrote: > Hmmm..... just reread your note... > > Are you suggesting that you could create new fields in the database > that serves ASM, that would NOT be ASM-reachable... but that could > be reached with a web-based MySQL interface? Bingo, spot on. > That would require > permitting some of the ASM fields to be queryable by BOTH ASM and > the web-based "VIM"... including the ability to correct information > in those fields by either interface. That's exactly how I'd design it. > Could work... although I'd > be a little concerned about multiple access unless MySQL can lock > fields that are in use by another user with another interface. > > It's not so much of an issue as you'd think, since ASM doesn't do any locking either and we have multiple ASM users updating things at any given time. IT's "Last to the gate gets the write", but the people using ASM are generally working on different things at different times, and we CAN build in locks later if need be. > I don't know how flexible MySQL permissions are... that is can a 'volunteer' > user have access to volunteer data including the required already existing > ASM fields... but not to others? > > If your app isn't querying the ASM fields that we're not presenting to people, then they have no access to those fields -- unless we screw up and leave a SQL injection bug or something. > Here's what my mind sees: unless MySQL's implementation has changed, > it makes files in a directory. MySQL is definitely not a filesystem based DB and has not been for a number of fields -- it's a relational database very much like Oracle. So, it has "tables". The "Owner" table currently has many columns, such as "OwnerName" and "OwnerEmail". If you have a web app that needs a "OwnerPreferredTasks" field (for example) we can add the column to ASM's "Owner" table. ASM won't look for that table, not knowing about it, and thus won't be affected by its presence. > So you would add files (fields?) to > that directory that would link to some (all?) of the 'people' fields > already there. The 'new' stuff would be things that are specific to > the volunteer database... and that ASM wouldn't even know about... and > accessible ONLY through the web-based interface. > > Is that possible? Is that the right way to think about it? > > Part of this was to avoid having to 'hit' on you every time there was > a need to change the database structure by adding (or removing) some > field or other. We were worried that since ASM needs to be secure > it would be easier for us to have a separate entity where if anything > went wrong, ASM was not at risk. > I appreciate the not having to hit on me for changes angle; I can be tough on security issues! But for longer term use you have to ask yourself "Do we intend for this app to get lots of use?". If the answer is yes, and it contains data that is also contained within ASM, you *will* get out of sync with ASM, and down the line someone will ask me to try to tie the databases together somehow to avoid getting the data out of sync. It's much less of my time commitment to help with the design process than to try to come up with glue later on down the line, with two disparate and distinct databases. > I'm certainly open to a solution that keeps things together... but I > didn't want to compromise existing operations. Chloe's involvement > is primarily to manage the volunteer data. She claims she doesn't > "even know what a database is". (I really don't believe that, but...) > > You're getting the thrust of my arguments correct -- I apologize in advance if I'm slowing this down any and I'm not prohibiting you from having your own DB -- just trying to reach what I think would be the best long term architecture, even if it takes a bit more work in the short term. Regarding compromising existing operations, I'm quite happy to make you a copy of the ASM database, call it "asmdevel" (in fact we already have one!) and let you knock away at your hearts' content on it, without affecting the real ASM database at all. Then when the app is ready for prime time, we just tie it back into the production DB instead of the development one. > Anyway... lemme know if I've got any of this right :-) > > -m- >

2 2

Re: [Mickaboo Techlist] Fwd: test newsletter
by AMuse 03 Sep '08

03 Sep '08

We have an email address which emails everyone in our list who hasn't opted-out; I have to specifically authorize you to send to it, but once that's done you would just email the newsletter to that list. Dianne Lynch wrote: > This would be strictly and eZine through email, thus eliminating any > printing or mailing costs.

1 0

Re: [Mickaboo Techlist] database
by AMuse 03 Sep '08

03 Sep '08

FYI, putting things into the ASM database does not require ASM -- just knowing what fields in the DB to update. It's no different accessing ASM's MySQL database than it is accessing your own that you've created. We can add new tables to the ASM database, which ASM software will ignore, and use them for the specific things your app needs. That way if your app queries for a name/address/phone number/etc it will get the one in ASM, and if it queries for vehicle, assistance, etc, -- it will get those tables too. People would not need ASM to access your application. If you make a separate application that also stores some of the info ASM stores, then in a few months to a year they'll be out of sync. Then you'll get into a situation where this occurs: * A person moves, and their phone number is updated in ASM but not the Volunteer database (or vice versa) * A person emails the list, says "Does anyone have X's phone number?" * One person emails back "650-123-4567" and another person emails out, "650-888-2222". * Now, which of those is actually the correct number? Who knows? Which datasource for phone numbers is -authoritative- ? I'm totally fine with developing a web interface for this code -- in fact, I encourage it! But if it's going to background against MySQL, and wants to use data we already store in ASM, it should pull the data that's in ASM from the ASM database rather than creating new copies of it in its own database. Mal Raff wrote: > providing new fields > > > Not sure that's what's really needed. I understand the synchrony > issue, but the databases are for different purposes. Certainly > could put everything in one place... and then I could write the > appropriate scripts to get the stuff out. But putting it in would > require ASM... and I think Chloe had in mind providing accessibility > to more than the ASM-able subset of people. Not sure... need to check. > > Is confluence not able to address more than one database? If that > is a problem then indeed, it will have to be additional fields in ASM. > > Some of the fields might be similar (name, address, phone, email, etc) > But for volunteer-task-specific items would it not be better to have > specific tables set up for that? Things like availability (time and > geography), resources (vehicle, assistance), facilities (temp storage, > etc), and so on.... > > There's also the issue of ASM. Chloe (and John, me too) use Macs. > The ASM interface, although improved, still has issues of not painting > some of the icons in the submenus. I use it with the old interface > software, which takes forever to paint the screen and still has the same > old problem repainting various screens. I think they were hoping for a > nice 'neutral' web-browser type interface (plus the scriptable command > line stuff). > > No problem... let me ask and we can get you a list of the sorts of > fields that might be good... in addition to the basic volunteer > information like name, address etc. > > Might be a day or so before I can get back to you... > > -m- >

1 0