RE: Why we should choose the RFC2821 MAIL FROM/HELO identities

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

> Layers are tools for design, as well as analysis.  Collapsing layers
> requires very, very careful attention to the implications.

When you are dealling with a twenty year old protocol you are likely
to find that the reason it is failing is that the original layering
design was inappropriate for current uses.

> In this case, one of the implications is to kill reall
> store-and-forward and real mobility, as has been described quite a few
> time.

This has been disproved repeatedly. There is no functionality loss
whatsoever. A tiny, insigificant proportion of users will have 
to bring their mail configurations into line with the overwhelming
standard practice.

This group is chartered to make a proposal. It is not chartered to
consider whether the proposal is or is not a good idea. 

> In the world of Internet protocols, options are often very expensive,
> adding quite a bit of implementation and operations complexity,
> increasing the likelihood of bugs, and often adding small practical
> value, unless used primarily as a means of evolution, rather than
> long-term variation.

Options that affect interoperability are a bad idea. That is not
what is being discussed here.

> One of the real secrets to Internet protocol success has been the
> definition of tight, useful protocols with common, core facilities
> that do not require options.  If you want to see an example of the
> alternative, take a look at the OSI protocols.

The real secret of the internet was it got lucky. If the Web had not
come along when it did and email had remained the killer app for another
few years the US federal government would have deployed OSI regardless
of technical merit.

The fact that a particular set of ideas was sufficient in 1992 does 
not mean that it continues to be sufficient in 2004. The patterns of
Internet usage and the trust relationships are far more complex. If
there was absolutely nothing wrong with the original design as you
appear to be insisting then there would be no spam and no need for 
this group.

> >> On the average, artificial intelligence algorithms do not 
> work well at
> >> the core of a high volume networking service like email.  
> Alas, that's
> >> the technical base that would be required to implement the sort of
> >> description-based service you (and others) are suggesting.

> As I said, this approach does not work for high-volume, transfer
> protocols.

This is false, AI scoring techniques have been at the heart of 
the card payments industry transaction systems for decades.

If you have an alternative proposal, make it to ASRG. If you have
no alternative proposal your comments are not relevant. We are
all aware of the points you keep raising, we just do not agree
with them.

If as you claim the corectness of the original design is proved by
its sucess, then the fact that spam outnumbers legitimate email 3 to 1
means that by your own argument change is essential.

		Phill