Subject: RE: How is SPF different from RMX?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Aug 2004 13:32:08 -0700

> I'll remember that quote next time I have something for Verisign to
> change.  

I think that there is a very big difference between a change that
costs a few hours of sysadmin time and a change that increases the
data volume in the .com zone by an order of magnitude.

It is one thing to demand that a change be kept to a manageable
proportion, quite another to demand no change at all ever. If you
were arguing that the spec should be changed in a particular way
to facilitate deployment that would be quite another matter.

> > Argument by reference to anonymous source is not very credible.
> > Give a specific example.
> 
> I think you follow Nanog, 

Nope, never have.

> and the recent lawsuit filed over renumbering.  
> Plaintiff claimed they didn't have enough time to renumber.  

Sure, I can see a potential cause of action there. But SPF is not
going to make any difference. The cost of renumbering is in the 
effort required to reconfig individual machines. If it was pure
DNS then people would not be getting steamed.

The effect of SPF is different, there is no obligation to 
deploy SPF. The only consequence of not deploying is that you
are going to find it harder to get your mail accepted by the
major ISPs. 

I don't think you have a cause of action here.

> If you don't or can't understand why not, then we don't have enough in
> common to communicate on the subject.  People depend on the 
> internet. We can't just break it.

We can't just do nothing while the spammers break it either.

Not doing anything has not worked to date and shows zero chance of
working in the future. Ergo a bias in favor of action appears quite 
justified.

> But there are some irresponsible people who disagree. 
> Fortunately, the responsible people are starting to look over their 
> shoulder, in case they really don't understand.

But as you yourself admit, you are not looking over our shoulder,
what you are doing is asserting that what we are doing is very likely
to be broken and that the seriousness of the consequences means that
you don't have to do anything to justify your assertion. 

I beleive that unless Sender-ID is deployed by the end of this year
the entire planet earth is likely to be eaten by a giant mutant
star-goat followed shortly afterwards by the collapse of the entire
space time continum. Since I am sure you will agree that these
consequences would be the most serious imaginable you won't be needing 
any justification.

> But here are some pointers from the code of conduct to help you:

Conduct, shmonduck, we have no time for those! Star-Goat! Star-Goat!

> 
>   2 # Take all reasonable steps to minimise waste of natural 
> resources,
>   damage to the environment, and damage to products of human skill and
>   industry.

'all reasonable' does not mean never do anything that might cause
people to need to change.

>   4 # Avoid deploying technologies that defeat generally accepted
>   technical principles of the Internet, as documented primarily by the
>   Internet Engineering Task Force (IETF). In particular, avoid
>   technologies that tend to subdivide access to the Internet 
> rather than
>   preserving its universal, unique, and international nature, 
> except as
>   required by security mechanisms mentioned in the next paragraph.

Since when was sending fraudulent emails a generally accepted 
practice?

> I not saying do nothing. I'm saying make sure it works, and 
> works in more than just trivial cases. 

What you are saying is that you want to argue against the proposal
but want to make your case impossible to argue against by refusing
to provide more than the vaguest of arguments.

Star-Goat! Star-Goat!

> Excuse me?  If the IETF cancels or doesn't approve Sender-ID it will
> happen anyway so we better work on it or else? Sure thing, 
> Osama. I'll get right on it.

Comparing people to a mass murderer probably counts as a personal attack.

Empirically SPF was happening before this group formed. If the IETF
was to go arround cancelling ideas without the slightest of justifications
as you appear to be advocating it is not going to be in the business
of making decisions very long.

If you want to stop something you need to give very precise reasons
not to do it. Vague possibilities of harm are no more of a reason for
not doing something than the star-goat is a reason to do something.

> Witch doctors shouldn't have promised the sysops and end users that
> something _could_ be done that can't be done.

You have failed to show why or how it can't be done.

> I'm the scientist who said that standing on your head will 
> not affect the rainfall nor the drainage.

Scientists do not make vague assertions and then refuse to 
support them. You have failed to propose any mechanism whatsoever.

> But the witch doctors have said other things in the past:
> 	Run Cancel bots, that'll get 'em
> 	Use this blacklist
> 	Kill the IEMCC, (it came back in CAN-SPAM)
> 	Use Pop before SMTP
> 	Use SMTP AUTH
> 	Use this other blacklist
> 	Use this whitelist
> 	Try this DCC thing

And I have been on record for many years arguing that most of those
was a terrible idea at the time. I argued against ARMM before it was
even launched and went amok. I argued against MAPS long before it
became fashionable to do so.

The only schemes that have had lasting value are authentication 
based schemes.

> None of that worked.  We are getting fed up with stuff that 
> doesn't work.

So, it is long past time to let the real security professionals
tackle the problem.
 
> I'd say SMTP AUTH was an IETF proposal to replace 
> Pop-before-SMTP. And 
> while the IETF carefully removed "spam control" from its 
> official goal, 
> that was in fact the goal of Pop-before-SMTP. 

SMTP Auth seems to be a better idea in principle than POP before SMTP
which was clearly a kludge.

And most people seem to think that it is a good thing to be able to
close down open relays and still relay legitimate email.

> So the IETF has had the opportunity to address spam, and is clearly 
> not ignorant of the problem, as you know very well from participation 
> in the DNSEXT namedroppers list where "spam control" was used to 
> abuse some participants over the last several years.

The DNSEXT group appears to believe that spam control is outside their
scope. Ergo there is not much that can be deduced from conversations
in that forum other than that they do not intend to consider it.

> Anyway, in compliance with the ISOC code of conduct rule 3:
> 
>   3 # If his or her professional advice is not accepted, take all
>   reasonable steps to ensure that all persons neglecting or 
> over-ruling
>   this advice are aware of the possible danger or damage 
> which may result.

This statement refers to 'the possible danger or damage', the use
of the definite article is surely intentional.

If the idea had been to consider the mere possibility that damage
might result then nothing would ever get done.

> I don't think many on _this_ forum agree with me to wait with 
> large scale
> deployment until more positive results are known. Though enough did on
> DNSEXT to kill RMX.  

OK so because you managed to kill the idea five years ago in 
another forum using scare tactics you don't need to ever give
reasons for your opposition again?

Star-Goat!

---

From: Dean Anderson <[email-masked]>
Date: Mon, 2 Aug 2004 18:34:57 -0400 (EDT)

> data volume in the .com zone by an order of magnitude.

Well, I haven't said either of these things. For some it might be minutes,
for others hours, for others days.  For all, very likely, lost mail, and
hours tracking down the problem.  For all, a constant, recurring
additional maintanence requirement.

Cost for the abuser:  a few days at most. Then nothing after that.

> to facilitate deployment that would be quite another matter.

I don't demand no change ever. I just think that there should be some 
benefit to the changes, and that they shouldn't be gratuitous.

> are going to find it harder to get your mail accepted by the

That's a pretty major consequence. Though, I don't think its likely that
major ISPs will ever be able to reject mail. Not for long.  I think most
likely scenario is that many of the millions of domains will remain
unconfigured or misconfigured, just like in-addr is today.

No large ISP was able to reject misconfigured[**] or unconfigured in-addr, 
either.  What makes you think that they will every be able to reject 
non-SPF domains?  That really mystifies me.

[**Radical antispammers have long proposed that in-addr checks can somehow
"authenticate" a source.  Not only was this proven to be a flaw in the BSD
r-commands, it was shown to be a false claim on both DNSEXT and DNSOP.  
In-addr will be impractical for IPv6 and has been replaced by Hostinfo. It
was discussed that in-addr should be dropped altogether from IPv6. Also,
ARIN has been considering not providing in-addr service. ARIN has gone so
far as to have its lawyers investigate whether they are required to
provide this service, and the lawyers say they aren't required to do so.]

> We can't just do nothing while the spammers break it either.

Spammers (as in Commercial Bulk Emailers) aren't breaking anything. The 
few that are, are handled by CAN-SPAM. But very few are violating 
CAN-SPAM.

> working in the future. Ergo a bias in favor of action appears quite 

A lot has been done, and nothing has worked. Makes one just about think
you might want to prove information theory the same way the 4 color
theorem was proven: by exhausting all possible combinations.

> you don't have to do anything to justify your assertion. 

In principle, thats exactly correct: The non-design community shouldn't
have to prove it won't work: Rather the designers should have to prove
that it will work. The IETF has at core the principle of "running code."  

But I am, in fact, going further and demonstrating that it won't work: the
abuser can simply adapt and continue forging email, or just stop forging
email and continue.

All that work, by all those production engineers in deployment. And for
what: Nothing.  Kind of reminds me of the gopher in the movie Caddyshack.  
You're playing the role of Bill Murray, going around with dynamite trying
to kill a gopher. The gopher just pops out another hole.  You have to blow
up the whole golf course, and in the end, the gopher just dances and sings
"I'm all right, nobody worry about me."  to the end credits. Its funny in
the movies. Its less funny in real life.

> consequences would be the most serious imaginable you won't be needing 

Thats about all I've heard so far as justification for Sender-ID.

Well, ok, that's not true. I've heard it'll solve the spam problem, just
don't look under the hood or run any serious tests until after deployment.  
Deployment is the test. 

> Conduct, shmonduck, we have no time for those! Star-Goat! Star-Goat!

Ok. 

> people to need to change.

I didn't say that.  However, "unreasonable steps" does seem excessive.

> Since when was sending fraudulent emails a generally accepted 

I didn't say that either.  Sending email is a generally accepted practice. 
Outsourcing is a generally accepted practice.

And your proposal doesn't prevent sending fraudulent emails. Even if it
were worthwhile to give up email and outsourcing, your proposal doesn't
deliver the goods. __Quid pro Quo__ If I give you my goods, you better
actually deliver your promises, rather than just make them. But you can't
stop fraudulent email, and so you won't deliver up your Quid for my Quo.

> to provide more than the vaguest of arguments.

Nonsense. You have to prove that you can stop abuse. I have shown that the 
abusers can still send abuse.  That isn't a vague argument. You've offered 
no argument at all that the abuse will actually be stopped.

> Star-Goat! Star-Goat!

"Spam! Spam will flow if you don't do this! Don't ask me any questions or 
have me bother to test it! Just do it now! Quickly! Quickly! Spaaamm!

Phillip had written:
> If the IETF does nothing then Sender-ID will happen anyway and
> all you will have achieved is breaking the IETF. The end-users 
> and the sysops are utterly fed up with waiting while nothing is
> done.

> Comparing people to a mass murderer probably counts as a personal attack.

Extorting the IETF by saying that it cannot disapprove the Sender-ID
proposal is probably a violation of the code of conduct.

> of making decisions very long.

Slightest justification?  Please be intellectually honest.  There isn't 
the slightest justification that Sender-ID or RMX can achieve its goals. 
That makes them both gratuitous.  

> You have failed to show why or how it can't be done.

Perhaps you haven't been listening. 

> support them. You have failed to propose any mechanism whatsoever.

Law Enforcement attention to virus operators. Law Enforcement attention to 
CAN-SPAM violators (there are few, but they will need attention)

> became fashionable to do so.

So have I.

> The only schemes that have had lasting value are authentication 

?? Which ones were that?  I think the only ones to have lasting value were 
DCC and Spam-Bayes.  But these are also defeatable.  They only have the 
lasting benefit that the abuser must continue to adapt as they adapt. Its 
a merry-go-round.

> So, it is long past time to let the real security professionals

Yes. Real security professionals realize that a police uniform doesn't
mean you are a police officer. Superficial identification is never more
than superficial.

> close down open relays and still relay legitimate email.

Neither Pop-before-SMTP nor SMTP AUTH had any effect. No effect 
whatsoever. 

And most of the people who thought that open relays were a bad idea have 
now closed up shop. They were always the ones that abused open relays. 
Open relay abuse has dropped to nearly nothing. Another "hoop" that didn't 
have any effect.

> in that forum other than that they do not intend to consider it.

That wasn't why RMX was killed. DNS protocol extensions is in the scope. 
And a protocol extension for Spam is no different than a protocol 
extension for AFS. (the afs extension was approved).

> might result then nothing would ever get done.

By some perhaps.  We usually keep root passwords away from those folks.  
Others are more careful, and consider the consequences of what they do
before they do it. I get the feeling that perhaps you are bit
reckless--seat of the pants, balls-on-fire, "torpedos? Damn the torpedos"  
type of fellow. That OK for a developer. Or a programmer. Or a protocol
designer. Its not such a good trait in a production operations person.

> reasons for your opposition again?

It wasn't with scare tactics, and it wasn't 5 years ago.  You have not
provided a single rebuttal to the examples I gave previously of how an
abuser can still send abuse. I demonstrated that abusers can still send
abuse. You haven't refuted that, and you accuse me of being vague and
using scare tactics. Please.

> Star-Goat!

"Spam! Spam will flow if you don't do this! Don't ask me any questions or
have me bother to test it! Just do it now! Quickly! Quickly! Spaaamm! Oh
my GAWD! Its full of SPAAAAAAAAAM! AIIIIHHHH"

Ok, enough for me.

		--Dean