[ietf-clear] No callbacks, please, was Re. CLEAR Charter

On Mon, 2004-10-04 at 03:14, Tony Finch wrote:

On Sun, 3 Oct 2004, James Couzens wrote:


SES is not written in stone, and there has been discussion relating to
permitting two different types of validation, both per user (which I
believe Tony Finch is after, and really is the right way to be doing it)
and per domain.


To expand on this, I am currently working on deploying a bounce address
authentication scheme at the University of Cambridge. I can't impose it
for both technical and political reasons. Technically, I do not have
control over all of the University's border email machines so I cannot
quietly slip an implementation in at that point of the system.
Politically, I work for a service organization without a monopoly and with
limited support resources; we can't force our users to change their
behaviour (to use SMTP AUTH etc.) even if it is for their own benefit.
Hence it must be optional, and we rely on the extra security and the
reduction in backscatter to encourage the users to change their setups.


As regards not having control over your border machines I should think
that your job is near impossible?  Through your use of the english
"Technically, I do not have control..." I assume that you do exercise in
someway shape or form control over them or else you wouldn't be working
on what you are working on.   That being said, I gather that this
control and the disruption that is resultant from any use needs to be
limited and painless so as to not rock the boat?

The "SES CB service" is easily implemented even on your network in spite
of a lack of control however by publishing the availability of said
service with an SPF modifier which SPF has been designed to facilitate
(ignorant clients simply ignore unknown modifiers).  Talks with Meng Wen
g Wong have rendered an immediate possibility of the addition of an
official mechanism to support this were the interest appropriate.

I find myself in an equally compromised position as regards the
political and monetary motivations behind the implementation of any such
technology.  On the one hand, our customers are sick of Spam.  On the
other hand they refuse through either a sick inability to use their god
given right to learn and think or simply through their own selfish and
ignorant want of doing whatever they please and "dear god I just learned
how to do this e-mail thingy this way, now you want me to learn how to
do it that way?!".  I've been told that under no circumstances shall we
put SMTP-AUTH into place, and this decision is the direct result of a
test that happened about a year ago that led to swamping our helpdesk
with cries of Armageddon and countless threats in addition to actually
loosing customers to our competition.

So really the only place we can look to is the servers themselves and
doing what we can to facilitate effective above all, with cost
reasonable to benefit, service(s) which perform braindead authentication
without the requirement of user input.  

I should like to update Ben Franklin's famous words of "In this world
nothing can be said to be certain, except death and taxes." and replace
death and taxes with politics and ignorance.

Cheers,

James

-- 
James Couzens,
Programmer
                                                     ( ( (      
      ((__))         __\|/__        __|-|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : 
http://mipassoc.org/pipermail/ietf-clear/attachments/20041004/e7694224/attachment.bin