wayne wrote:
In
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)0(_dot_)20040106152821(_dot_)02722d90(_at_)mail(_dot_)declude(_dot_)com>
"R. Scott Perry" <sce-spf_discuss(_at_)declude(_dot_)com> writes:
I can't wait until everyone fixes SMTP everywhere so I don't have to
resort to challenge/response spam killing like I do now.
*Please* do not use C/R!
I agree, C/R systems are bad. However, much of the damage that they
do can be reduced if they used things like SPF. A C/R system should
*never* send a challenge if the SPF check fails. IMHO, a C/R system
should *only* send a challenge if the SPF check succeeds. I suspect
that most C/R proponents will still want to send challenges if the SPF
check says "unknown".
I like your thinking, though I'd say rather that badly-done C/R systems
are bad :)
I agreed that Challenges should not be sent to forged addresses (which
is why I decided to start using SPF in the first place).
I think that I'd go as far to say that I'll personally turn off C/R on
"pass" checks, since these would either be from blacklistable servers or
real people.
As for the "unknown" checks, I suppose that's a matter of opinion, but
it sure will encourage people to start using SPF :)
Is the python implementation of SPF good enough to try and get the
TMDA folks to use it?
I tried to look at this, but it looked to me like the link was down.
Oh, wait, it's up again. I'll take a gander and see how it would work
with TMDA. However, I think that SPF should really be done at the MTA
level, so I am going to suggest to Jason (author of TMDA) and the other
developers that we should start looking for the Received-SPF header and
acting on it.
--
Jim Ramsay
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡