Randy "PerlStalker" Smith wrote:
Julian Mehnle wrote:
If you think that SPF or DK will stop spam, you're certainly on the
wrong
track. These are sender authentication technologies, and if spammers
use
their own domains in the sender address (which is actually what we
want),
none of these technologies will be able to stop their spam.
You are, of course, right. However, by rejecting messages that fail
SPF and DK checks, I can "trust" that the message was send from a
server under the sender's direct control. I can use this trust to
blacklist "authenticated" spammer domains. I can also drop mail that
fails authentication attempts which actually will (and does) limit the
amount of spam I get to deal with in other ways.
Well, I'm totally confused what point was being made. Cause you
basically just said the same thing Julian did. :-) My understanding of
your original message was that you weren't happy with the results you
were getting from SPF to block spam. But ignoring for the moment that it
doesn't actually block spam, there is another reason that SPF (or even
DomainKeys) won't be that useful right now. Not very many domains have
actually implemented it (them). And until that happens, the utility of
having them configured is questionable.
For myself, I have left SPF checks run in advisory mode for a while
now... almost two months. And the amount of mail I receive from domains
where SPF has even been implemented (results other than "none") is very
small. Naturally, I'm not interested in turning blocks on now because
virtually all my mail would spill out into oblivion... :-)
The real effort to make it (them) more useful is to build awareness and
widen adoption...
Bill
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] DomainKeys
