From: Alex van den Bogaerdt
Sent: Sunday, May 30, 2004 6:39 PM
On Sun, May 30, 2004 at 04:02:00PM -0500, Seth Goodman wrote:
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.
"allow for rejection before data" != "must reject before data"
I'd like to make that choice myself, as do many users. Next thing
you know there's spf.rfc-ignorant.org listing people who don't reject ...
(no, I am not against rfci)
There a lot of choices that a lot of people would like to make that cause
them to damage other systems. Store and forward mail systems that send
bogus bounces to innocent domains are a good example. They are a remnant of
the old internet. While SES does provide a way to protect an individual
domain from accepting bogus bounces, it does not prevent a store and forward
mailer from bombarding the rest of the net with bounces appearing to
originate from your domain. Store and forward systems that use SPF and
don't reject during SMTP are forced to silently drop mail, which violates
the RFC's. While silently dropping forgeries is certainly the lesser of two
evils, SPF gives us a tool to avoid that in a lot of cases.
Store and forward mailers act as forged bounce spam amplifiers and there is
little, if any, justification to operate in this mode. At least in terms of
SPF detectable forgeries, they can be determined during the SMTP session, so
there is no reason to accept a known forgery. If SPF is to protect other
people's domain names, this is a reasonable requirement for the standard.
While any loss of personal freedom of choice is regrettable, the damage
being done by such systems, IMHO, justifies some restrictions. It is
arguable that this is similar to the open relay situation, forged HELO
strings, etc. If the RFC's used MUST instead of SHOULD in a few key places,
we probably wouldn't even need SPF.
If SPF ultimately does come to pass, I hope that there _is_ a DNSBL such as
the one you mentioned for systems that don't reject SPF detectable
forgeries. It would be a perfectly reasonable and self-protective action to
reject mail from systems that knowingly accept forgeries.
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.
I'm sure it will be possible to create an email that passes, say,
SpamAssassin
yet being sent in your name not from your domain. Remember, SPF
!= anti spam.
Quite true, but depending on how someone sets up their SPF record, it will
not be easy to create an email that passes SPF and fraudulently uses their
domain name in the return-path. SPF == anti-forgery.
--
Seth Goodman