Login bug
Squashed a nasty bug, well actually a lack of implementation. After converting some of the web pages to PHP I neglected to implement Login in PHP! Now implemented.
" />
« November 2003 | Main | March 2004 »
Squashed a nasty bug, well actually a lack of implementation. After converting some of the web pages to PHP I neglected to implement Login in PHP! Now implemented.
Added new "Space Usage" report. Not sure if I like this because 1) it's too slow and 2) the resulting report is not very impressive - it's just a line saying "User is using X bytes in the databsase". Might wish to implement a space counter in the user table. This would require that all procedures updating the database update the space counter. The intent for this space counter is to judge how much space a user is using in the database for the purposes of quotas or perhaps to charge people if they want more space.
Also, currently this space report is only counting space used in the email table. Might wish to add in the log table, which can add up, and the user and useropts tables. The latter two are minimal but including them would make the report more accurate.
Many, many improvements have happened to MAPS. I have not been keeping this blog up to date. I will try to do better. Here are some of the things that have been implemented or improved:
That said here's a bug:
When an entry is added to a list the system now searches the other lists and if a matching entry appears in another list it is deleted. This effectively "moves" the entry. Problem is that the delete does not resequence the list that it deleted the entry from.
We should also consider decoupling the sequence # concept. I don't think it is necessary anymore. MAPS applies filtering based on lists - order doesn't seem to be important.
We might also consider not basing the stats and detail pages off of the log entries but directly off of the email in the email table.
Might wish to implement a "super white list". Super white list would be bascially the users address book. The "other" white list would be entries added by registration. User should be able to promote from white list -> super white list. The difference is that the super white list would be applied before other lists. Currently MAPS processes lists in the following order:
This way the user can apply special privilege for some users. For example, I'd really like to null list all of the *.br$ spam I get but if I did I could not get email from my dad in Brasil. If I had a super white list I could add his address to it and then nulllist everybody else.
We also need to figure out how to handle spam I get when the spammer sets From to be me (or anybody else on my white list). I was thinking about an X-MAPS header that I could set for myself. This would not solve the problem of a spammer sending me spam from somebody else on my white list though I've yet to see that - it would be rare. Except for domain whitelisting such as *@defaria.com. Not sure how to address that