Alan,
My comment was that an architecture with everyone using a central server
is not an "edge" architecture. It is an infrastructure architecture.
AD> Your original message said "services", which was ambiguous.
I use the word 'service' to refer to an entire, end-to-end
activity. Frequently, discussions fail to attend to effects over the
whole system (service), so I tend to focus on that.
AD> When I
AD> responded, I intentionally used the phrase "protocol deployment at the
AD> edge", which was an attempt to define what I was talking about.
AD> Infrastructure already exists for most organizations to accept
AD> email, and forward it from a well-known MTA. The only thing that
AD> may need change is the edge, to get them to use the existing
AD> infrastructure. So this isn't an architectural change, it's an edge
AD> change. It's deploying pre-existing protocols to nodes on the edge.
I think this particular disconnect between our terms of reference
occurs pretty frequently. You are describing a bunch of components
that exist. Hence I believe you are thinking of "infrastructure" as
referring to a core set of routers over the "default free" (backbone)
public Internet. Hence, all of the email components under discussion
are outside the infrastructure.
I am using the term infrastructure as describing a particular service
architecture. For example, a service that is a collection of user
nodes around a central server means that the server is an
infrastructure component and that the overall service is completely
centralized.
MTAs provide email transfer infrastructure. Yes, it is frequently
worthwhile to distinguish between first- and last-hop MTAs, versus
intermediate MTAs. The first and last ones
AD> We know how to do this. We can do this. It can take less than 3 years.
The number of components that need to participate in an MTA
registration scheme, the administrative overhead for the operations
staff, and the fact that this is all being retro-fitted into an
existing service all point towards much, much longer deployment times.
My other comments highlighted the architectural differences between your
example and architectures like email.
AD> Deploying SUBMIT to edge nodes involves no architectural changes to
AD> SMTP.
It involves changes to service operations infrastructure, to cause
SUBMIT to be supported. Then it requires changes to each end node,
which is problematic for regular users. All of this points towards a
slow adoption.
AD> Any requirement that an anti-spam method have zero impact on all
AD> roaming users is a requirement that we do nothing to stop spam.
I don't recall anyone requiring zero impact on roaming users.
AD> Any
AD> requirement that the architecture of SMTP cannot change is a
AD> requirement that we do nothing to stop spam.
I don't recall anyone requiring zero change to SMTP.
In both cases, the concern I am raising is a) being careful and clear
about the nature and degree of impact, and b) the nature of the effect
from the change. (ie, cost/benefit.)
AD> The question then is: What current classes of use are you willing to
AD> have affected by schemes to fight spam? What are the bounds on
AD> tolerable affects?
it does not involve hard (and/or arbitrary) limits. it involves
trade-offs, but this requires assessing the details carefully.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>