1) I feel that no other solution other than pure whitelisting will work in the long run. I have had my personal email address for many years and there are days when I receive over 1000 spams per day. I am currently using several public blacklists and SpamAssassin set at its most aggressive setting, which worked for years until a few months ago, but now spammers are getting very smart about bypassing normal anti-spam tools. What alternative would you propose to whitelist-only email?
There are tech solutions such as TDMA, bayesian analysis, Yahoo's domain keys (my personal favorite). There are legal solutions of giving right to sue for clear spam violations (I think with your litigious view of the world, you would find this the most effective). There is also process solutions where the spam catcher (tools and rules) gets regular updates to catch the new spam approaches. There are commercial offerings that do this, and in the long run I expect an rhupdate approach to spam catching where you regularly download the latest set of tools. Spam evolves, so the spammer tools and catching rules evolve too, and you just need a process that allows your spam catcher to evolve without you having to worry about it.
2) I know that creating a new "reply" email directed to the "from" or "reply-to" address can be abused for relaying. But wouldn't a reject of the incoming SMTP transaction itself (with an appropriate error message) go back ONLY to the real sender? The point is that if somebody isn't willing to go through some necessary hassle the first (and only the first) time he sends email to me, then that person is not someone I want to hear from - EVER. I am assuming that the mailet API is called -->before<-- the transaction is complete. And of course, there are situations, like when joining a mailing list, where whitelisting would have to be done in advance by the recipient. But please correct me if I am wrong.
Rejecting the SMTP transaction itself is less spoofable, but then you can only receive email with servers able to accept this approach (since rejecting in SMTP transaction means you cannot provide a length explaination for the rejection, nor a link or information to join the whitelist).
Next, spammers can parse the whitelist approval form and get on your whitelist (anything you do that allows your mother to join your whitelist will allow a spammer to do the same).
With address-whitelisting (as opposed to TDMA server-whitelisting), a spammer could still send you spam, by spoofing a sending address of someone on your whitelist.
Servers that are configured (ignorantly or maliciously) as open relays get around the benefit of rejecting during transaction.
With respect to your belief, "if somebody isn't willing to go through some necessary hassle...", say you send a message to me and mispell my name (you wouldn't be the first). My mail server (from the postmaster address) sends you a bounce email saying your email didn't get to me because the email address you typed was wrong. You think my postmaster is going to join your whitelist so you can know about your mistake?
No, the mailet API does not (yet) support rejecting in SMTP transaction.
In terms of joining a mailing list... I mean, this is so fraught with problems, I'm not sure where to begin.
a) how do you know the sending address of the mailing list before you join?
b) what are you basing your whitelist restriction on? SMTP sender, Reply-To, To, From? If you're checking the SMTP sender, then mailing lists using VERP would screw you and so you'll never receive a message (each delivery from a VERP-enabled mailing list sends with a unique from address so it can track which message bounced).
c) different mailing lists act differently... some set a reply-to, some put its address in the from, some leave it alone so you only see it in the to or cc, someone could bcc a mailing list so you don't even see a header about that mailing list.
d) every bit of this is spoofable, so if I see you're on a mailing list and your whitelist somehow handles that, I can just send you a message that pretends to be from the mailing list.
This is just off the top of my head... certainly a spammer would figure more holes since they're financially compensated to.
-- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
