ietf-asrg
[Top] [All Lists]

Re: [Asrg] Spam, why is it still a problem?

2006-01-18 02:49:59
Barry,

You make some good points, and althought I accept that I don't have the
answer I'll try to illustrate what I mean by rising to your challenge..
Effectively in my view, the difference between a "new" protocol and
enhancements to existing mechanisms is that a new one would be able to be
designed such that transmission of messages was denyed by default, enabled
by choice and could be revoked at will.


          (I'll call that the First Axiom of IFUSSP)

Sounds good, but I claim there is no such solution, or it's never been
outlined that I've seen.

Thats probably true, but we can guess what elements it would include.

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.
What I do know is that it is possible to design systems which satisfy
bounded requirements.
The variability comes in because no-one has yet defined those requirements
unambigously, all we have is unbounded requirements or requirements which
are based on concepts which have no commonly accepted definition (such as
"spam"), and commonly stated requirements which are sometimes incompatibly
different depending upon what role you are playing in the system.

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
2/ it would not involve any charge being levied for transport (even an
indirect charge like cpu cycles)
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)
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.
5/ it would not impose additional direct or indirect loads on external
systems, don't shoot the messenger.
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.

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.

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.

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.

Mail could be accepted into the recipients domain by checking only that it
held a validated identity.
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.

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.

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

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.

d.



***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) 
only. If you are not the intended recipient (or responsible for delivery of the 
message to the intended recipient) please notify us immediately on 0141 306 
2050 and delete the message from your computer. You may not copy or forward it 
or use or disclose its contents to any other person. As Internet communications 
are capable of data corruption Student Loans Company Limited does not accept 
any  responsibility for changes made to this message after it was sent. For 
this reason it may be inappropriate to rely on advice or opinions contained in 
an e-mail without obtaining written confirmation of it. Neither Student Loans 
Company Limited or the sender accepts any liability or responsibility for 
viruses as it is your responsibility to scan attachments (if any). Opinions and 
views expressed in this e-mail are those of the sender and may not reflect the 
opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the 
presence of computer viruses.

**************************************************************************

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>