On January 18, 2006 at 09:39 Danny_Angus(_at_)slc(_dot_)co(_dot_)uk (Danny
Angus) wrote:
So let's just have this IFUSSP design, please. Or let's stop claiming
it exists.
I haven't heard anyone claim it exists, there is a key variability.
I think they have, every time someone prattles on about how
internet-wide deployment is a difficult constraint. A difficult
constraint on what solution, precisely?
IMHO any "IFUSSP" solution would probably need to meet the following
requirements..
1/ it would allow unknown (new) senders to *attempt* to send mail to any
user of any domain
Agreed.
2/ it would not involve any charge being levied for transport (even an
indirect charge like cpu cycles)
Unclear. TANSTAAFL, at best you can only shift the cost around.
3/ it would involve the use of open standard identity and trust mechanisms
to associate levels of trust with people and domains (no one will want to
re-invent that wheel)
Maybe, or maybe only for those who can't live with modest resource
needs. For example, I don't have to identify myself in any way to drop
a first-class letter in the postal box. But if I want to do much more
than that id requirements rise (e.g., my own postal meter.)
4/ it would not require a centralised register, nor require the use of any
commerically controlled register, it would be capable of benefiting from
operational efficiencies achieved by the use of chains of trust.
Not clear. Again, TANSTAAFL. Maybe we've gone as far as we can on
these ideas.
5/ it would not impose additional direct or indirect loads on external
systems, don't shoot the messenger.
Well, not without appropriate recompense or justification.
6/ unit cost of normal operations would not increase. For instance if a
proposal increases the cpu cycles required to accept good mail rather than
reducing the cycles required to reject unwanted mail then as the number of
unwanted messages presented falls the total cost might fall but the unit
cost rises and any increases in allowable traffic become more expensive to
accomodate.
This is probably getting too close to the nitty-gritty of a possible
solution vision to bother specifying so precisely. I'm not even clear
the requirement is all that necessary, seems like more of an
efficiency measure and a platitude to try to keep efficiency constant.
It might involve the exchange of trust tokens (and other domain details)
between unknown parties as means of registering allowable senders *before*
any attempt to send will be accepted. Trust tokens could be accepted at
face value where out-of-channel mechanisms for establishing trust exist
(for example between corporate domain operators) or some third party trust
provider could be required as a signatory for anonymous or less trustworthy
domains.
And these "trust tokens" can be managed without measurable expense? Or
the expense reasonably distributed to the end-users so dilute enough
to be negligible?
I'm not so sure, seems to wave a hand at the realities of managing
hundreds of millions of whatevers in some consistent manner.
The recipient system would respond at its convenience when the identity of
the sender (and any other checks which the recipient chose to make) had
been verified and accepted. The senders system would then, and only then,
attempt to send mail to the recipient.
That is, some magic token is exchanged and a system is postulated for
verifying that token against some set of trust criteria, and because
it sounds kind of difficult we'll not require that it be in real-time
even though we don't know what it is or whether it could work in
real-time or not?
I think we need the spec before deciding whether or not it might run
in real-time.
For example, characterizing most denial of service (DoS) [qattacks as
overloading a target system with transactions of some sort,
particularly if they can't be brushed aside in a lightweight,
real-time manner, DoS seems to potentially lurk in any system like
this.
Recipients would be able to revoke this permission at any time, resulting
in an end to all traffic from the sender for a period stated in the
revokation.
That is, criteria for acceptance are changeable and at least in part
under the control of the intended recipient.
Mail could be accepted into the recipients domain by checking only that it
held a validated identity.
As a proper subset, sure, but that's probably the easy case.
Recipient systems could continue (as at present) to scan content, the
difference being that in the new process it would actually be possible to
block the transmission of unwanted content, not simply to can it after it
has consumed resources. If people managed to circumvent the personal aspect
whole domains could be blocked. Where chains of mail transport exist chains
of trust could be established, recipients could chose to block incoming
mail that their domain might accept.
Chains of ... , hard part of the problem.
Also, the precedent seems to imply that someone else is blocking
content as a service, which has implications for both control, cost,
and immediacy (real-time-ness), maybe.
The key is that at each step in the transport of mail it would be possible
for a recipient to effectively turn-off the source for a finite or
indefinite period of time.
(or other criteria, e.g., until they stop sending more than one msg
per hour to me?)
Obviously without the existence of some clear (i.e. codifiable) definition
of what is accpetable one person might object to mail from a sneder which
their neighbour considers relevant and desirable, to this extent the
solution doesn't and cannot by defninition, prevent all unwanted content.
This is one of the sticky implications of "must not impose charges".
Either something is charged for fairly, or someone has to act as
policy commissar as to what merits delivery and what does not.
Perhaps in an ideal world that policy commissar making the rules is
the end-user. But as we've seen it's not as simple as that. E.g., can
I decide I want mail from a source which is threatening to bring down
my mail operator's facilities, purely on strength of policy (it's my
right to receive the mail I want), but without recompense?
So at least sometimes someone else is the policy commissar.
Unless there's some kind of fair charge in which case one can have
anything they like so long as they are willing to pay for it.
What it can do is to allow (but not compel) recipient users and automated
systems to identify the senders of unwanted content and disbar them from
even attempting to send mail.
To them, but whose responsibility is this? To actually execute, I mean.
I know this isn't the answer to your question! ButI hope it does
demonstrate that there are ideas out there which could form the basis of a
new form of SMTP which would permit some of the key requirements for
controlling the sending of unwanted mail.
You probably don't need much modification on SMTP to do most anything
since it's just a "COMMAND OBJECT" protocol (e.g. HELO systemid) and
can be extended just by adding another COMMAND and some typical rules
about WILL/WONT CAN/CANT and backwards compatability if desireable.
--
-Barry Shein
The World | bzs(_at_)TheWorld(_dot_)com |
http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg