spf-discuss
[Top] [All Lists]

SV: Security Paper on forgery bounce DDoS

2004-04-20 00:54:19
Many e-mail systems
are silently removing worms and spam today, if not most e-mail
systems.
Many systems do this because they are up against the wall, but that
doesn't
mean it is a good practice or that we want to keep doing this in the
future.

Good point - I was so blinded by the amount of spam that a future
without it wasn't in my mind :-)

OK, here are the two flaws that I feel are the most important.
Because of that design
choice, the return-path must be rewritten at each forwarding hop.

I don't see this as a flaw - it would be better if this was not
necessary, but I still think that SPF is the best design that I have
seen.

This is
complicated and is the source of a lot of the resistance to SPF
adoption.
To some people, SRS is a deal-breaker.  That would be a pity.  I would
prefer to see SPF modified so that SRS was not necessary.

True - but I still haven't seen a better replacement for SRS. This is my
personal opinion, of course.

If there is a second forwarder, their passing the message on asserts
that
the return-path was valid in terms of SPF when they received the
message,
but also implicitly that it was valid at all preceding hops.  When the
message reaches the final destination, an SPF pass result gives you,
at
best, a "composite" assertion as to whether the return-path at the
first hop
was valid.

I wouldn't set up my SPF system like this. I see the world like this:

- SPF filtering is done when the message leaves the sender's network and
enters the receiver's network. There is one hop where SPF filtering is
done. Period.
- Those few people that do forwarding out of their own network, have
several tools to help them rewrite the e-mails, so that they comply with
the above. They can attach the original mail to the forwarded e-mail,
they can use SRS, they can use whitelisting of the forwarding server
etc.

I imagine that less than 1% of all internet users would ever require
SRS.

Not many people are forwarding e-mails. Most ISPs deliver a mailbox,
which is emptied using POP3. Most e-mail clients can empty multiple
mailboxes today, and frankly, I don't know anybody besides myself,
who has a forward on an e-mail that they can't handle this way.
Don't say that in front of the large companies (like pobox.com) who are
primarily email forwarders!

Lol... I think that's too late to change now :-) But I assume that
pobox.com knows how to do SRS...

Whitelists can work, depending on your environment.  I should point
out that
a whitelist is valuable to the extent that you can verify that the
mail
actually came from the whitelisted address and is not a forgery.

My point was, that you don't have to verify it, because there are
zillions of e-mail addresses, and the spammers don't know which ones
that are whitelisted at your place. It actually works without
verification! If I whitelisted all e-mails from asdf(_at_)asdf(_dot_)com, this
would not suddenly make me receive a lot of spam e-mails with the
from-address asdf(_at_)asdf(_dot_)com(_dot_)

Well, I doubt that even most early adopters and SPF evangelists would
trivialize the SRS issue like that.

For some people, you need to explain how to do things - like forwarding
using SRS. All details of the SPF technology must be in place, otherwise
SPF would not be adopted. But this doesn't mean that all users care
about all details. Personally I would never use the macro features or
the explanation feature - for some other people it's quite important.

If you don't block on SPF fail results, you don't get much benefit
from SPF.

In a big organisation, you don't start to block things from day one, if
you can start blocking gradually. You start out giving small spam points
for SPF fails, and if no emails are in the "doubt" bucket, you increase
the number of points gradually.

I've seen several webhotel providers, who block everything on just a
single cause - like blocking everything that is blacklisted in spamcop.
This is totally ridiculous, since some e-mail hosters cannot avoid being
in spamcop from time to time. SPF is like that - what would the result
be, if you just blocked 5% of all potentials customers to an online
service? Maybe their earnings were 5% of the turnover...

Though you can use it as an additional clue for post-SMTP content
filters
like SpamAssassin, how many messages does this additional clue push
over the
spam threshold?

With time, I guess quite a lot, especially those sent by viruses and
worms, where the sender address typically is forged, but somebody we
know (and therefore often has SPF records). And frankly, I hope that the
next version of spamassassin also gives points for the default SPF
record "v=spf1 A MX ?all". This makes sense in my world.

He's doing what he needs to do to get SPF adopted as quickly as
possible.
However, I agree that this timetable is optimistic.  That's OK, he's
not
going to get it adopted by being a pessimist.

Maybe it's optimistic, but spamassassin is one of the tools that people
like to upgrade quickly, and when the next release comes, SPF filtering
will suddenly be the most deployed technique of those which are similar
to SPF.

Huh? Personally I don't care if an e-mail contains a forgery in
sender
e-mail address, as long as I want to read that e-mail. SPF doesn't
I suppose we disagree on this one.  I have no interest in reading a
message
that I know has a forged return-path.

Let me mention a couple of examples:
- Test e-mails delivered using "telnet mailserver 25"
- Webpage formmails that have not been programmed correctly (users hate
it when they don't receive those, and they typically bounce into
/dev/null)
- E-mails from your mother who mistyped her e-mail address when she
switched e-mail software
- Forwarded e-mails from a non-SRS compliant forwarder ;-)

I'm here strictly talking short-term wishes - in the long run, I hope
that SPF will be as authoritative as MX records.

Lars.