> It's just an old habit. When I learned SQL I was taught (mostly from > the big SQL books) and of course the little black book of normalization, > _Handbook of Relational Database Design_ that table columns should try > to be unique yet understandable.
ahh. I started db stuff with filemaker (allows whitespace in field names) and then moved to hand-created (perl flat text) and mysql.. guess my programming variable naming conventions stuck with databases. anyway... ;) > Hmm that is a good point. I think I will take a closer look at the > headers to see which to parse up. Certainly From, but also maybe > Subject and the IP information from the last Received header... That > should be enough to start with and yet have a wide variety of data to > choose from. Now I've got another table brewing, one with the msgid and > the from, subject and last Received: header data. :-) "last" received? or "first"? (meaning to say, the oldest). anyway, yeah, that's probably accurate enough. Subject should also be a good one, except for the few spams that put your name (or what they think your name is) into the subject. You could also check reply-to or mailer-agent (or whatever its called).. From doesn't always work so well since a lot of times it falls into the undisclosed.recipients@my-server or new.customer@my-server, or whatever. I'll start paying attention to that info, too... > Yes. I think that SA's auto-whitelist works similarly. Of course if > you're running IMAP the converters aren't so important. :-) yeah, it does. I was very impressed by this feature, actually.. and you're right, the auto-whitelist feature probably negates the need for something like an addressbook check. _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that’s a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
