Mailinglist Archive: opensuse-security (297 mails)

[suse@xxxxxx]

Quoting Alan Hadsell <ahadsell@xxxxxxxxxxxx>:
>
> suse@xxxxxx writes:
>
> > I don't understand why SPF blockers don't simply check ALL of the
> > received headers and "pass" if the proper mail server is anywhere in
> > the chain.  It's a simple and obvious fix for the problem of
> > forwarding without forcing anyone to change their mail servers...
>
> "For every complex problem there is an answer that is clear, simple,
> and wrong."
>  -- H. L. Mencken
>
> 1) You don't have the Received: headers until the SMTP handshake is
>    completed and the data is transferred.  At that point in the
>    protocol, there is no way to reject the mail; the receiving MTA
>    has taken responsibility for it.
>
> 2) Any Received: header other than the first (i.e. the last one
>    generated) could be forged.  You need to walk back through the
>    headers and identify, at each step, whether you trust the "received
>    by" host to correctly identify the "sent from" host.  This is a
>    nontrivial task.
>

And for every complex problem there are a dozen solutions that create more
problems than they solve.

1) Why is it necessary to block before data is received?  SpamAssassin and DSPAM
don't.  In fact, I much prefer systems that do not block at the SMTP.  If I
receive the e-mail and mark it as spam, it can be checked later.  If it's
blocked at the SMTP, there is no recourse.

2) I could also create subdomains on the fly, generate SPF entries, and spam
past SPF to my heart's content.  Until SMTP is completely replaced, there are
always ways around things.  The Spammers are clever.

Spam is like AIDS, there is no silver bullet solution, but a cocktail of
solutions will keep it at bay.  Strict domain checking, Blocklists, and DSPAM
have been doing a pretty good job for me, even though my e-mail addresses are
plastered all over the web.

The trick is to make certain that each step in the cocktail doesn't block
legitimate e-mail.  An SPF-style system that checked received headers would be
a great addition.  It's one more hoop for the spammers with very little cost on
my end.

Currently, SPF creates a blockage that is exceedingly difficult to remove. 
Trying to convince a hosting site to change it's e-mail system isn't trivial. 
People get REALLY upset when their e-mail doesn't work, so companies are very
wary of making any changes that could potentially cause problems.

I've noticed a correlation between proponents of SPF and people that never have
to actually deal with customers.  If I ran some internal corporate network, SPF
would look an awful lot better.  When you have a captive audience, it's much
easier to deal with complaints.