Delete bug

February 16, 2004 12:24 AM

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:

1. Went live 12/10/2003! We are now using MAPS from the Linux system and using the MySQL backend.
2. Many improvements and implemented a lot of the pages
3. Started re-writing things in PHP. PHP is pretty cool and now that I have mod PHP running it's also quick. I suspect that if I managed to get mod Perl installed that that would solve some of the sluggishness of the Perl pages, however PHP is more "web friendly" and it's nice not having to write a whole web page just because part of it will be dynamic
4. Implemented most of the "list" processing. You can now add/change and delete entries in the various lists.
5. Details.cgi needs some work but otherwise is functional. You can even select entries and say Add to Null list, etc.
6. Implemented Returned Messages by Domain report (in PHP)
7. Updated the look of the register and blacklist return messages
8. Implemented the Forgot Your Password link
9. Making pages have refresh option so that Quickstats updates itself. Added time to Quickstats
10. Implemented search facility to search sender and subject in returned email. While this is helpful it's not finished yet. Also takes a long time on a large message base...
11. Changed MAPS to only send return message once instead of up to 5 times
12. Changed MAPS to use envelope address if From address is blank

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:

• Check null list. If found send message to /dev/null
• Check black list. If found send blacklist.html to the sender and discard message
• Check white list. If found deliver message
• Otherwise return message (if we have not already returned a message for this sender)

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