[sub] [Sussex] re:- Phil Turners last post

[Steve Dobson]

Hi Nik

On Sun, Mar 07, 2004 at 03:10:43PM +0000, Nicholas Butler wrote:
> Cheers Steve...

Hey, a little fun and thinking on an otherwise boring Sunday.

> okay lets get into this <grin>

Yes, lets.
 
> >Yes there are times when sending a link is the best way to disseminate
> >a document's content.  But your solution will not work in every situation.
>
> Okay ... but I dont believe I can think of any technical Solution that 
> works in every situation.

True, and we are not here.  We are looking at a change in the current,
flexible (and abusable) e-mail system.

>                           In fact I believe the generalisation of Email 
> leads to its flexibility.

I thought that was my stance no yours :-)

>                            So im not interested in analysing a specific 
> case  that narrows down the solution to a point where the answer fails 
> to operate in the given scenario, since we can do this for any technical 
> answer.

But you are proposing to replace a tool that I use in a number of ways.
Unless you can provide a replacement that is, at least, as good as what
I currently use, in *all* the ways I use it, then where is the incentive
for me to change?

> And so far no one has disputed that people want to associate a file with 
> a communication.

Of course not.  If I was to send you a paper document via snail-mail then
I am likely to also send a covering letter.
 
> >Nik, what if 3ait and uThink where involved in complex talks about a new
> >kill app that would take over the world and establish our two companies
> 
> You see , here is where youve gone to a specific within the context of 
> this thread and I would point out that large or small my RFC for the MTA 
> delivery of attachments would still deliver on its requirements.

Of course, your RFC is a theory for a better replacement for e-mail.  I
only have to find one example were if fails to disprove the theory.  If
I do then you must do one of the following:
  * accept that it is not a full replacement and another protocol as
    well if all e-mails current rolls are to be replaced, 
  * revise your theory to allow for that example as well, or
  * drop your idea and keep with current e-mail system.
 
> >If you wanted to send me your latest changes to the-master-plan.txt are
> >you going to have that placed on a public FTP server for all to read?
> >Even if you encrypt the document it is still weaker then encrypting it
> >and sending it as an attachment in an e-mail.
>
> Im not suggesting a FTP or HTTP server per se, although the technology 
> is where you wish to implement a answer.

Why do we need a new protocol? Would this one be called ADTP (Attached
Document Transfer Protocol)?

>                                           Also note that my RFC suggest 
> that the MTA is responsible for stripping the attachment outbound and 
> storing this at some secure location with relevant authentication applied.

This is a massive area where your RFC breaks down - see below.

> I dont beleieve the arguement for better security through profundity 
> works either since if Mark H wants to access the document in the current 
> schema he can choose to attack more than one site. This also means that 
> should he gain access to the document then a aguement could be made from 
> Either company that the other was lax in its security over protecting 
> the Intellectual property.

Agreed, both systems fail if security at either end is lax.  But your
system requires that a server be on-line, and therefore available to
attack, just in case I want to read the document you sent.  If we both
have a copy of the document we can *both* move it to very secure area
(pull the network cables for example).

> Meanwhile if im responsible for the MTA and more thant the recipient is 
> able to collect the file then there can really be only one person 
> responsible for that security of that server.

Agreed, so that person better be highly paid and skilled at that job.

> Document Obsolensence and Old documents and historic Sent documents is a 
> problem. yes.

Good, I'm glad you see that.

>               But now were into the realms of ISO and British Standards. 
> But let me address it like this...

Nonsense.  E-mail attachments not only "associate a file with a
communication" (your words not mine) but also define the state of the file
at a given moment in time.  You RFC has to retain that information or it
degrades the quality of the communication system.

> When you receive the attachment you generally use some variety of SAVE 
> as at some point. If however you simply leave the attachment, choosing 
> to store it in your inbox or some folder then you have that privilege.
> 
> In the new MTA it would have to be established that the recipient would 
> have downloaded a copy , therefore you dont delete form the MTA 
> _FILE_STORE files which are unviewed. Now this allows another feature of 
> Auditing and Accounting for every file sent and every file viewed.

True, auditing is better.  But how do you cope if the outbound e-mail
get lost in transit.  I never get the e-mail so I will never notify
the MTA that that FILE_STORE reference count is out of sync.  I may,
if I am expected it, ask you to re-transmit.  If your system reduces
SysAdmin involvement how does this help?

At the moment there is a very, very loose coupling between MTAs and MUAs.
Your RFC requires a much tighter coupling.  Messages have to be sent from
my MUA to you MTA/FILE_STORE to try and maintain state.  Restorations, 
system crashes will have a much bigger impact on the other systems in 
the network.  This is not a good thing!!!!!  It will take extra SysAdmin
time to clean up both of our systems.

> Now if they do copy the document, whilst you view it at square zero lets 
> now examine the case for unwarranted .zip files sent by sucker X. Since 
> the FIle is most likely Spam/Junk/Virus there is now the ability of 
> Virus Software or "aware" users to respond to the MTA_FILE_STORE_manager 
> that the file is unwarranted and should be restricted until it can be 
> approved by the originating user. 

And how is this better?  You are asking me to trust that your
MTA_FILE_STORE is not holding Spam/Junk/Virus.  While I (just may) trust
you, Nik, I do not truss everyone that I am allowing to send me e-mails.

> >To summarize: The more flexible a system is the more it can be shaped in
>
> yes but youvenot really addressed the concerns withing the issue of 
> Email that currently it carries more Payload than Pay off within its 
> attachments.
> 
> Your arguement is the case that the Mail System should be left alone and 
> unrestricted. I agree with this precept. Im suggesting however that the 
> File Swapping mechanism of Attachments needs revisiting since its 
> "quite" clearly creating more work and effort than benefits.

Disagree - see below.
 
> >When systems are flexible it not only becomes possible to use them in
>
> Id argue that there is now more flexibility in the new MTA requirement 
> and it delivers better accounting and security for File delivery to 
> users via EMAIL , which is currently a major headache for many corporates.

I agree yours has better accounting, but not better security!

> >It must, therefore, be a priority to educate people to use those systems
>
> Well in this environment we no longer need to educate the users, since 
> its apparent that we can deliver a fix to the mechanisms that enables 
> the users to have more protection.
> 
> >To summarize the summary: Flexibility leads to invention and the creation 
> >of wealth, but people need to be educated to use the tools at their 
> >disposal wisely.
>
> Thats 2 summaries <Grin> anyway , how is my suggestion less flexible ?  
> As i see it the benefits of the new system would be
> 
> 1. Reduction in Bandwidth for Mail Delivery between MTAs.

True, but only at the expense of increased MUA/FILE_STORE bandwidth.  As
every time I view a document not SAVED to my system I have to go to the
FILE_STORE to retrieve it.  Do you have shares in Cisco or something?

> 2. Increase in Auditing and maintaining files delivered and received.

Yes - your system does do that.

> 3. Faster ability to respond to Junk Files and Virus files without user 
> interception.

No - not at all.  You place the onus on the outgoing MTA which, as I pointed
out above, cannot be trussed.  My MTA still has to validate the "remote
attachment", and it can only do that if it takes a copy and modify the e-mail
so the the attachment URL is to my local FILE_STORE.  This is no different
that the current MTA configuration.
 
> >To summarize the summary of the summary: People are the problem!
>
> Yes, remind me then ... Was it computers or people that wrote the 
> software which we all love and enjoy ?

Yes people created the software and the software allowed for the problem
so therefore people create the problem.  But people create all problems.

--------------------

Now to take each of your points and tear them to bits - sorry :-)
                                                                                
> 1. Attaching and sending files with an emails is creating badness on the
>    network

Only in that it allows for people to attach "bad" files.  Your system is
not stopping that just, changing the delivery method and detection points,
and in many ways for the worst.

> 2. Attaching a File and storing at with the originating MTA would be better.

No
   * Remote sites have to trust an MTA/FILE_STORE not under their control.
   * Added network bandwidth needed between MYA/FILE_STORE
   * More reliance on remote severs - the M$ model.
      - You couldn't read the attachments while off-line.

> 3. One copy of the file which can be put up and pulled down allows
> sysadmins to target potential viruses being sent out and remove the link
> immediately they cant delete files in another users inbox.

Sent out yes, but not received.

> 4. Dont stop users attaching files to an email  , but dont let them send
> out 100 copies of a file since its a big waste of bandwidth when you
> consider that the recipient will effectively have to download that file
> either as a Attachment or a link. Allow a user to send 100 links, but
> let the MTA manage setting up the link,  and let the server manage the
> attachment and the access to that attachment.

My as my MTA must pull the file from the FILE_STORE to verify its contents
are safe we get more network bandwidth used.

Currently MTAs do not send multiple copies of the e-mail body if multiple
e-mails are going to the same host.  In this "push" method duplication
happens at the very last possible moment. Less WAN bandwidth.

> 5. Fix the MTA to let it know where attachments are and how to manage them.

But in doing that reduces security and increase network bandwidth.

> 6. Plain text emails never hurt anyone except by flames .

Damn. I agree with that one.

Steve