Subject: RE: How is SPF different from RMX?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 1 Aug 2004 20:07:21 -0700

> 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.

As far as the IETF is concerned all working groups are peers. The
fact that a group has been arround trying to finish its work for 12
years does not seem to me to be a recomendation of its expertise,
quite the opposite in fact.

> 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.

> > , so every domain that has an admin maintaining it should be able to
> > afford it -- and those who do that externally actually pay for a
> > service, don't they ?
> 
> 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.

> 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. 

> "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".

> 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.

> 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.

> So, it seems that you have to track down virus operators and 
> put them in jail. 

Have you got a problem with that objective?

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.

Sender-ID provides some very useful features for both stopping
the propagation of viruses and for catching the criminals.

---

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

> they have successfully deployed DNSSEC and it is in use by 5% of the 

Hahahaha. Touche.

> Try a perl script. If you manage hundreds of domains you are familiar 

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?

> It is pretty easy to set a system up so that your changes propagate

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.

> 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.

> but I am sure that there is one and my time is too valuable to

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.
> 

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,

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.

> Have you got a problem with that objective?

No problem with that. That is the only solution I see.

> 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".

> 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