RE: E-mail vs. FTP -- ***RTF RFC***

[owen () dixon delong sj ca us (Owen DeLong)]

I fight FUD almost every day.  The reason FUD succeeds is because
people who know better are too lazy to fight it.  Sure, it seems easier
at the time, but in the long run, it just makes all of our lives harder.

If you give a mouse a cookie, it will come back for a glass of milk.

Owen

> One of my clients, a largish dot-com, tried this ... resounding lack of
> success. The end-user community did NOT like it when an email arrived with
> links. They were too afraid that the link might point to a virus, among
> other things (yeah, I know, but YOU try fighting FUD for a while).
>
> > -----Original Message-----
> > From: E.B. Dreger [mailto:eddy+public+spam () noc everquick net]
> > Sent: Saturday, May 26, 2001 7:57 AM
> > To: nanog () nanog org
> > Subject: E-mail vs. FTP -- ***RTF RFC***
> >
> >
> >
> > Greetings all,
> >
> > Section 7.3.3 of RFC1341 addresses the external storage, 
> > expiry, et cetera
> > issues.  Not perfect, but a good first pass... and almost ten 
> > years old,
> > too.
> >
> > ((( Thanks to Valdis for pointing this out! )))
> >
> > We could probably kludge FTP as an interim measure:
> >
> > * MTA intercepts attachments, and spools them separately.
> >
> > * "access-type: ftp" with, e.g., username "msg12345recipient67890" and
> >   password "mi93et490" and "expiration: Mon, 28 May 2001 
> > 00:00:00 +0000".
> >   The specific parameters would be generated on a per-message basis.
> >
> > * Mail admins can enforce quotas.  Nothing new.  The 
> > arguments in favor of
> >   electronic transfer are on the grounds of timely communication.  One
> >   could argue that somebody not checking mail for a week 
> > doesn't deserve
> >   to receive their attachment without a second 
> > "transmission".  The proxy
> >   MTA could insert a human-readable expiration notice or 
> > whatever other
> >   user-friendly prompting is deemed to be a good idea.
> >
> > * We could also forget the MIME method, and put in a 
> > human-readable link
> >   to get the attachment, a la electronic greeting cards.  
> > This would allow
> >   immediate use of non-registered access-type methods.
> >
> > Eventually, I'd like to see this done via HTTP/1.1 using chunked
> > transfers.  However, no current MUAs will support a non-existant HTTP
> > method or any X-Experimental methods.  For something that would work
> > *right now*, I think that RTF RFC and going from there is the 
> > right way...
> >
> > Does anybody know what MUAs follow the RFC for external 
> > message content?
> > A little smtpd and ftpd hacking could yield something workable PDQ.
> >
> >
> > Eddy
> >
> > --------------------------------------------------------------
> > -------------
> >
> > Brotsman & Dreger, Inc.
> > EverQuick Internet Division
> >
> > Phone: (316) 794-8922
> >
> > --------------------------------------------------------------
> > -------------
> >
> > Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
> > From: A Trap <blacklist () brics com>
> > To: blacklist () brics com
> > Subject: Please ignore this portion of my mail signature.
> >
> > These last few lines are a trap for address-harvesting 
> > spambots.  Do NOT
> > send mail to <blacklist () brics com>, or you are likely to be blocked.