Dave Crocker writes:
You make a reasonable point. Unfortunately there is a
cost associated with that sort of generality. Protocols
that have this sort of flexibility tend to be more
complex, more buggy and slower to get adopted.
Then you tell me: who is the "originator" of a piece of mail
through a remailer?
In fact I think that that is an entirely reasonable question.
I view the difficulty of answering that, based on current
Internet standards, as supporting my comment about excessive
flexibility.
Flexibility that we have to live with; this train
has long since left the station.
The difficulty in answering that question is impeding current
anti-spam work, in my view.
I don't feel impeded. The nice thing about signing is that
you aren't forced to make this arbitrary decision about
"originator" as you are with the path based methods. The
sender fundamentally doesn't know or care the ultimate path
and expansion it may take. The receiver decides all on its
own what it cares most about. The only maxim is that if you
sign it, you own it (perhaps jointly).
If MASS is to produce something quickly that is adopted
quickly, it needs to be absolutely as simple as we can
make it. This means limiting options and variable as much
as possible.
It adds no complexity to the sender(s); the infrastructure
required is identical. The receiver may or may not deal with
the additional complexity.
Receiver complexity can be a major obstacle to adoption.
Further, the more critical dependencies there are in a protocol's
adoption, the less likely it is to be adopted. My sense is that
the relationship is inverse and exponential.
I don't know what "critical dependencies" you're talking
about. In my prototype of IIM, it checks to see if there's a
signature for the From domain, if it works and is authorized
all's well. If it's broken and there's a Sender header, it
uses that as a sufficient backup. Other policies could be
devised for the receiever. I don't see how this qualifies
for Film at 11 complexity pronouncements.
Mike