Alan,

It was a technical decision made to improve performance. Your suggestion was actually our 1st implementation... But...

If 50 users receive the same spam message, and only one of those users decides to force-delivery of that message to his mailbox, things can get tricky. If we only stored (for storage capacity optimization) only one copy of the message that was linked to all 50 recipients, we'd need to keep pointers and counters so that the message does not get deleted until ALL 50 users have passed their retension period, and that it does not get deleted if any of those users either force deletion or  force delivery of that message. This is all very possible to implement, but requires more database query overhead. The greatest concern was performing database cleanup routines, where the expired messages are deleted from the database. Having to keep track of the above pointers/keys in the database was greatly reducing SQL performance during massive delete operations, so we opted to split the messages, one for each users. It resulted in more space consumption, but there was a huge performance gain. We opted for the latter, and chose performance over higher disk useage.

Roberto F.
LogSat Software

Nothing would change on the Bayesian side of the story since we're only changing how the information is stored in the database. That data is not related to the way Bayesian tokens are extracted and saved.

Roberto F.
LogSat Software

That would not be correct.

Emails with multiple recipients can arrive in 3 ways. Assume an email to one recipient and 2 carbon copies. In all cases the email body and email headers will be exactly the same. Please note that it is in the headers that you find the To: and CC: headers that cause the email clients to display the To and CC labels.

1. The sender's SMTP server connects to SpamFilter, sends a RCPT TO command for the TO address, sends the email headers/body. Disconnects.
   The remote server reconnects again to SpamFilter, sends a RCPT TO command for the 1st CC address, sends the email headers/body. Disconnects.
   The remote server reconnects again for the 3rd time to SpamFilter, sends a RCPT TO command for the 2st CC address, sends the email headers/body. Disconnects.
2. The sender's SMTP server connects to SpamFilter, sends a RCPT TO command for the TO address, sends the email headers/body. The sender then issues a RSET command to start over without disconnecting. The remote server then sends a RCPT TO command for the 1st CC address, sends the email headers/body. Then it agains sends a RSET. The remote again sends a RCPT TO command for the 2st CC address, sends the email headers/body. Disconnects.
3. The sender's SMTP server connects to SpamFilter, it issues consecutively a RCPT TO command for the TO address, then another RCPT TO for the 1st CC, then another RCPT TO for the 2nd CC. It then sends ONCE the email headers/body, disconnects.

Of course you'll say "why in the world doesn't everyone use option 3 since it takes up the less bandwidth and resources?". Well... if there's an answer to that we sure have no idea what it would be... But unfortunately there's providers (even very large ones) who still use  1 and 2. And of course they will generate a full message and a file to scan for each CC. To SpamFilter, 1 and 2 will look like completely independend emails since they were sent us such.

Again, all we're doing is that when a "smart" sender uses option 3, we're simply splitting the message up and storing a copy in the database for each recipient. We're not caching extra "files" on the disk since that would slow down the A/V.

Roberto F.
LogSat Software

We are simply

I think we need a way of specifying maximum number of AuthTo errors from one IP and disconnecting. Some of our customers are on mailing list where every member of the domain gets a email, all from the same mail server at one time (because its more efficient). We have had to bump up our Max RCPT up to 30 to prevent those on mailing lists from getting stuff rejected.

This still lets the the dictionary harvestors keep plugging away at least 30 times before getting stopped by Spamfilter.

We need a tarpit mechanism where excessive failures of AuthTo from one IP be disconnetc for x minutes.

Andy

557 You exceeded then maximum number of RCPT TO

Obtaining adresses without knowing anything of the people who own the adresses will result in you spamming people.

Sending advertisements 'blindly' will get you blacklisted, since a percentage of people will have no need whatsoever for your product and will declare it spam. If enough people receive your 'spam', a blacklist is unavoidable, non-profit or not. Software like spamfilter ISP exist because of the sheer amount of garbage that lands on our digital doorsteps and this is exactly what it tries (an succeeds) to eradicate. I would suggest you look for other methods of reaching your market, doing it by blind mass mailing (i assume this since you say you need half a million adresses or more) will only guarantee one thing; your ip blocked.

Because e-mail is for free, and because it reaches millions of people with no effort at all, it is beeing abused. The good suffer because of the bad.

Sorry if i sound harsh, it's not my intention, but you need to know the risks when sending these amounts of e-mails, however noble your product may be, a percentage of people will regard it spam, and with these numbers of mails even a low percentage WILL get you blacklisted.