On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote:
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.
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.
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.
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.
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.
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.]
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.
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.
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.
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.
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.
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.
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.
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.
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!
Ok.
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.
I didn't say that. However, "unreasonable steps" does seem excessive.
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 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.
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.
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.
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.
Extorting the IETF by saying that it cannot disapprove the Sender-ID
proposal is probably a violation of the code of conduct.
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.
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.
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.
Perhaps you haven't been listening.
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.
Law Enforcement attention to virus operators. Law Enforcement attention to
CAN-SPAM violators (there are few, but they will need attention)
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.
So have I.
The only schemes that have had lasting value are authentication
based schemes.
?? 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.
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.
Yes. Real security professionals realize that a police uniform doesn't
mean you are a police officer. Superficial identification is never more
than superficial.
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.
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.
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.
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).
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.
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.
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?
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