spf-discuss
[Top] [All Lists]

RE: What about reverse source path?

2004-05-30 14:02:00
From: Nico Kadel-Garcia
Sent: Saturday, May 29, 2004 10:35 AM


<...>

If SPF is used, not to block non-SPF-compliant email entirely,
but merely to
affix an SPF header reporting on the SPF compliance, that's an extremely
useful header to to parse for client filters. It allows the user to
implement as personal policy what to do with those emails.

I should point out that one of the longstanding goals for SPF was to allow
rejection of forged envelope sender email _before_ DATA.  The current
converged SPF/CID proposal blocks anything that gives an SPF result other
than PASS (as we don't yet have a draft, I don't know whether it is MUST or
SHOULD).  I have argued in other posts that MUST is the better way to go,
and I still feel that is the case.

If all SPF does is tag suspicious email to use as an additional factor in an
after-the-fact content filter, I don't see that it's worth the effort.
Bayesian filters already work extremely well, SpamAssassin works extremely
well and some commercial content filters work extremely well already.  One
of the things we all want to get out of the SPF effort is a way to stop
accepting the deluge of messages that have to be queued, delivered, filtered
and manually reviewed by the user to cull false positives.  A false positive
(due to misconfiguration of the sender's SPF record) that results in
blocking of a valid email will also result in a DSN to the sender.  A false
positive from an after-DATA content filter will often be missed by the user
in a large spam folder.  That being said, if people want to use SPF as a
tagging scheme, that's certainly their choice.


For that use, Windows client support is vital.

Outlook currently has built-in rules that can trigger on specific phrases in
the headers, so no changes are needed to accomplish what you suggest.  I
don't know about Outlook Express.

--

Seth Goodman