ietf-asrg
[Top] [All Lists]

Re: [Asrg] 0. General

2003-10-31 12:44:36
At 5:27 PM -0500 2003/10/27, David Maxwell wrote:

A DNS server being compromisable is an implementation flaw, not an
infrastructural one. It's also more difficult than forging an email
address is today, thereby raising the bar for spammers.

      No more difficult than writing a virus to compromise millions of 
PCs world-wide and make them available to you as open proxy servers.

You didn't respond to my comment. I said A > B. You said B !> C.

   Of course, another issue with open caching/recursive servers is
that you can get anyone in the world to effectively host your domain
for you, and combined with wildcards they could appear to be hosts
for virtually all domains on the Internet.

I don't understand your example.

      Then you don't understand enough about DNS security issues to be 
able to pass judgement on these matters.

No, you simply weren't clear enough about your example. I can't use the
argument "it isn't" to accuse you of naivety in matters of foreign
currency exchange, and you can't conclude anything about my
understanding of DNS security issues with a comment like the above.

Right, it's raising the bar, and it's also enabling other tools.

      It's not raising the bar.  It's moving the bar, but merely 
horizontally.  You're not improving the situation.  Moreover, because 
you're moving the bar into territory where many admins have much less 
knowledge and experience, in many ways you're making the situation 
worse than it was before.

Saying that 'things will be different, and people will have to adapt' is
not a reason by itself to not make a change, otherwise no changes could
ever be made. It raising the bar - it will allow detection/rejection of
a particular class of abuse - including the forgeries from well known
sites, such as paypal and ebay.

For the below, you clipped a critical line of context from my reply, so
I'm re-inserting it:

(All the following is with the exception of point-to-point user
verification, such as PGP signed messages.)  

Without (verified) domain names, you can't have verified email
addresses.
      Not true.

Care to back that up with an explaination? The only one I see is the
cryptographic solution (which I mentioned as an exception, though you
clipped it). Cryptographic solutions have keying issues, which gives
solutions not dependent on crypto certain advantages, particularly in
implementation.

Without (verified) email addresses, you can't have reliable user based
whitelists.
      Not true.

Care to back that up with an explaination? Simply negating my statements
does not contribute to the discussion.

I believe that for many users, a short whitelist would be a highly
practical solution to the spam problem. It wouldn't be for myself,
personally - but for my mother, and my aunts...

      It wouldn't be useful for anyone who doesn't understand the 
details of the technical implementation, and who doesn't know what 
the potential failure modes are and what to do about them.

What? Please explain how my mother would need to understand the
technical implementation in order to be able to say "I accept mail from
a(_at_)b(_dot_)com, and c(_at_)d(_dot_)com, period."

      In other words, the people it would be least useful for would be 
your mother or your aunts.

Any white or black listing proposal which doesn't address the need for
authentication of the list compared data may be worked around.

      Anything which causes the trust boundary to be crossed can (and 
will) be gamed.  This is where joe-jobs come from.  Authentication 
methods won't change this fact, unless they are based on a secure 
protocol which uses strong crypto at the core -- which means that 
they cannot possibly be implemented through the DNS.

You're talking in absolutes, but I think there's a range of gray area
here.

In my view, joe-jobs come from the protocol accepting 'MAIL FROM:' (or
HELO, or the message header) on faith, and performing no checks on it
whatsoever. Sure, adding checks which aren't cryptographically strong
means that people will try to work around the checks, but it would still
be better than no checks.

You seem to be arguing that we shouldn't do _anything_ if it isn't
perfect. Since no solution will ever be perfect by everyone's
definition, they we will never to anything.

Come to think of it, I've never seen you mention what spam solutions you
think are beneficial - only interfere with discussions of solutions you
don't like. What solutions do you like?

                                                        David


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>