RE: EMAIL != FTP

From: Jim Mercer [mailto:jim@reptiles.org]
Sent: Friday, May 25, 2001 4:03 AM

> So what's a regular user to do? Email it! Hence the
legitimate use of
> email for transmission of large files. Most ISPs know that
if they start
> limiting this privilege, users will migrate to someone that
allows it.

i regularly configure ISP's with a limit on the size of email
messages.
(generally 10meg, although i think 100k is probably better).

That's why most corps use their own MTA's. Sometimes, I run into a client
that has such bigots running their systems. A few "failures to communicate"
usually result in executive management applying the clue-by-four. Business
rules drive technology, not the other way around. One clueless company even
blocks attachments with more than one dot in the name. They are steadily
losing business.

One does not give access to passworded sites without an NDA. After the
initial deal is set, one does NOT strike clients in the face with security.
Security need to be transparent.

when they get a complaint, i then point them to the fact that
many of the
large email messages get stuck in the queue because the receiving side
is too slow or doesn't have enough disk, or the users quota is full.

At $99 per 40GB HDD, there is no excuse for lack of space. MTAs should
delete all messages once they are sent, or soon thereafter. My laptop is
considered small ... at 12GB. BTW, end users DO know how to delete files and
manage space. The file cabinet metaphor works well.

and of course, the sending user hears that it wasn't
received, and then assumes it was lost and resends it.

... and the system should accomodate them.

file transfer by email is evil.

That's your unsupported opinion.

i've been saying that for literally 10 years now:

... and you never wondered why no one listened?

> From: Jim Mercer [mailto:jim@reptiles.org]
> Sent: Friday, May 25, 2001 4:03 AM
>
> > So what's a regular user to do? Email it! Hence the
> legitimate use of
> > email for transmission of large files. Most ISPs know that
> if they start
> > limiting this privilege, users will migrate to someone that
> allows it.
>
> i regularly configure ISP's with a limit on the size of email
> messages.
> (generally 10meg, although i think 100k is probably better).

That's why most corps use their own MTA's. Sometimes, I run into a client
that has such bigots running their systems. A few "failures to

communicate"

usually result in executive management applying the clue-by-four. Business
rules drive technology, not the other way around. One clueless company

even

blocks attachments with more than one dot in the name. They are steadily
losing business.

One does not give access to passworded sites without an NDA. After the
initial deal is set, one does NOT strike clients in the face with

security.

Security need to be transparent.

> when they get a complaint, i then point them to the fact that
> many of the
> large email messages get stuck in the queue because the receiving side
> is too slow or doesn't have enough disk, or the users quota is full.

At $99 per 40GB HDD, there is no excuse for lack of space. MTAs should
delete all messages once they are sent, or soon thereafter. My laptop is
considered small ... at 12GB. BTW, end users DO know how to delete files

and

manage space. The file cabinet metaphor works well.

Last time that I checked, adding a drive to a raid array or NETAPP was a
great deal more than $99. Lets not count the cost of upgrading a HD in a
lowly Linux box (not bashing Linux here). IDE is also not sufficient
enought in order to sustaint the write rate of that these servers demand
(let alone the IO). 5200 RPM drivers are not a solution for ISPs.

> and of course, the sending user hears that it wasn't
> received, and then assumes it was lost and resends it.

... and the system should accomodate them.

> file transfer by email is evil.

That's your unsupported opinion.

An this is your unsupported opinon. Have you ever dealt with many corporate
customers that complain that it takes 2 minutes to open up their mailbox
(thats what you get for a 250 MB mailbox). Its one thing to receive such
mail and another to ensure that you mailbox doesnt get overfilled. What
about resources used by a box that has dozens of POP3 sessions that are
locked due to client software timeouts?

FTP = GOOD
MAIL ATTACHMETS = BAD