On Sun, 1 Aug 2004, Hallam-Baker, Phillip wrote:
In this respect, RMX was probably better. But it was still rejected
because
It didn't solve the problem and was therefore gratuitous.
The DNSEXT group can be regarded as an authority on requirements after
they have successfully deployed DNSSEC and it is in use by 5% of the
internet.
Hahahaha. Touche.
Setting anything is "a matter of minutes for one domain".
Try doing it
for hundreds or thousands of domains.
Try a perl script. If you manage hundreds of domains you are familiar
with this type of issue.
I'm sure register.com and Verisign and other lowcost hosting places are
thinking the same thing. So, who pays the perl programmer? Do they work
for free at Verisign?
Service that doesn't include 20% increase in frivolous domain record
maintanence: And it is ongoing maintenance. Change the IP of your
mailservers, and lots most stuff has to change. It gets
correspondingly
more difficult to renumber.
It is pretty easy to set a system up so that your changes propagate
in the right way.
Some say otherwise. Some say it takes six months now to renumber IP
addresses, and we are going to add even more work to that task.
22,000 out of perhaps 22 million domains? That's less than
one tenth of
one percent. I'm sure more than that use "hair growth cream".
It doesn't
matter how many use it if it doesn't work.
Its rather more domains than are using DNSSEC.
Well, I don't think DNSSEC will work either. I've said it many times.
That's another poorly thought out, but desperately needed function. But I
think they should keep working. When they get it to work, it will be
useful.
"It works for me at the moment" is not a sufficiently
convincing technical
analysis to spend a great deal of money and inconvenience a
lot of people.
??? The argument here seems to be of the form "I don't know
what the problem is going to turn out to be with this protocol
but I am sure that there is one and my time is too valuable to
bother looking for it".
Yes. Thats exactly right. I expect the protocol proponents and design
engineers to do this work (ie, the people on the list who think this is a
good idea), not the production network engineers (ie not the people who
will have to fix things on the fly when their mail to AOL.com breaks
suddenly).
We can't accept "I don't know what the problem is going to turn out to be
with this protocol so lets just put it into large scale universal
deployment in 8 months and see what happens. I am sure that whatever
problems found will have to be solved by others and my time is too
valuable to bother looking for it now".
Gee thanks. Now there is nothing to make those events less bad. Keep
shooting us in the foot, folks. Maybe you'll hit something vital. Or
maybe, you'll just kill something like outsourcing email, and no one
will notice.
Perhaps if you read the actual documents you might be able to
state how one of these calamaties might occur.
Its a bit difficult to disprove a claim that is not even stated.
Doesn't seem like outsourcing is going to work at all. I already gave as
an example scenario of real Av8 Internet customers who send email from:
<user>@earthlink.net Earthlink has to add all of Av8 Internet's IP address
space that is or might be assigned to that customer. Possibly, if Av8
does the relay, as opposed to direct sending by the Av8/Earthlink
customer, then earthlink just has to permit the AV8 Email servers that
might be used by that customers. That would have to be maintained. Anytime
Av8 changes a server, it has to coordinate that with Earthlink and every
one of the other 30,000 ISPs out there whose customers outsource or might
outsource from.
Before something will be accepted, it needs to work for a long time.
That means that it has to do more than just break the current and past
abuse engines for a few days. It has to break them permanently. Wait,
information theory says something about that. It says you can't ever
achieve that.
Nonsense. We are in the process of applying a priority list of things
to fix in the mail system. SPF is not the only fix that is necessary,
it just happens to be first on the list.
In an ideal world the IAB or IESG would be providing a priority list
of things to fix. Since they have not others have decided priorities
instead. If you feel that other priorities should be attended to
then submit a proposal.
Then get back to me when you have a system of changes that will solve the
problem. I don't want to do a bunch of stuff that won't solve the problem.
Been down that road far too many times in the last 8-10 years.
So, it seems that you have to track down virus operators and
put them in jail.
Have you got a problem with that objective?
No problem with that. That is the only solution I see.
It seems to be working to the extent of filling up the jails.
There has been an indictment in the Sasser/Netsky cases, successful
prosecutions in many others.
Yes. It is not a problem finding the people who do things when the
incentive to find them exists. It is not a matter of "can't find them",
it is a matter frequently of "No significant cost damage so Feds won't
bother to even look for them".
Sender-ID provides some very useful features for both stopping
the propagation of viruses and for catching the criminals.
I think you need to substantiate that. All that is necessary to track
down virus abusers is already there: A time and an IP address in the
received header. Nothing else in the message is relevant (other than the
virus itself, or the abuse content, that is). SMTP AUTH doesn't help with
this. Sender-ID isn't going to help either, since it can always be
spoofed for the same domain. Even if that weren't the case, those
credentials can be stolen and used on another computer, so fixing this
case isn't useful. Having fixed it, you have achieved nothing.
It isn't useful at all for stopping the propogation of viruses, unless you
assume that the virus writers won't adapt. This is a frequently-made, but
invalid assumption.
--Dean