Bruno.Melloni@nokia.com wrote:
> 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. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
|