Re: EMAIL != FTP

[Craig Partridge <craig () aland bbn com>]

In message <GNEIJMGJNDJMNEGPDBGBAEJGDHAA.rblayzor () thebiz net>, "Robert Blayzor"
 writes:

> I think you missed the fact that sending files via SMTP is incredibly
> inefficient.  Any files sent via SMTP have to be encoded which can balloon
> the transmission up 30%+.  That is an incredible waste of bandwidth on a
> 10MB file.  Also, remember that SMTP usually relays, so the message is
> bounced between 1-8 servers along the way (or more), more bandwidth and
> resources wasted. *sigh*

I've gotten a bunch of notes on this topic.  Issues in order:

* Email encoding is inefficient.  It doesn't have to be.  A zipped
  uuencoded file is often smaller than the source file and rarely
  longer.  Why not update the MIME standards to encourage compression
  of binaries?  This is the network operators mailing list -- you can
  certainly go to IETF with operational concerns and have credibility.

  Then we could block attachments that don't implement the new encoding
  and, hey, actually improve the world!

* SMTP usually relays.  Yes it often does.  Typically you'll relay a couple
  of times.  But most of those relays are at high bandwidth locations with
  lots of disk space -- they're not suffering.

* A POP site may find itself storing 200 copies of the same binary.
  That's true, and a problem.  There's an obvious solution: do what
  mail daemons do and share the file among mailboxes, but that solution
  increases risk of corruption (e.g. the pointer to the file gets trashed
  and you retrieve the wrong attachment).  

In short, I'm not sympathetic with the first two concerns.

Craig