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.
participants (1)
-
E.B. Dreger