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!