RE: Email messages: How large is too large?

["Mason, Shane" <smason at blockade.com>]

But I can do that already, by sending an email with a huge attachment direct
to your SMTP server that has a destination with a name and IP, but no
physical site.  It will stay at your site until your SMTP timeout kicks in.

This is, of course, assuming that the RFC still says all SMTP servers must
accept mail to any destination, and your site is RFC compliant.

What about an SMTP server negotiating a size limit based on a profile for
the mailbox of the recipient?  Or perhaps a hold and verify, so the
recipient is notified of the document, it's size, who sent it, and at what
time, and then the recipient could send an ACK or a FIN for immediate
delivery or immediate bounce BEFORE it travels to the recipient's mailbox.

ICMan

-----Original Message-----
From: Vernon Schryver [mailto:vjs at calcite.rhyolite.com]
Sent: Friday, December 17, 1999 2:50 PM
To: ietf at ietf.org
Subject: Re: Email messages: How large is too large?


> From: Valdis.Kletnieks at vt.edu

> ...
> No, it would be an old protocol.  See RFC1440, from July 1993.
>
> Is there sufficient interest to create a working group to overhaul RFC1440
> into something more usable in today's Internet?

In today's internet, filled with mentally challenged hacker d00ds, who
would allow any installation of a protocol that could fit the title
"Sender-Initiated/Unsolicited File Transfer" to move files larger than a
very few MByte, or what SMTP can already be (ab)used to move?
"Unsolicited" is the killer.

In other words, do you still have a writable anonymous FTP area?


Yes, I agree that is still entirely possible and quite desirable to have
a writable anonymous FTP account, but only if you erect sufficient
defenses, such as limiting file sizes and names and making files written
by outsiders unreadable by outsiders (thus fixing the warez/gif plague),
and if you are willing to deal with endless shrill warnings from CERT and
many other well meaning parties that your anonymous FTP area is writable.

Could such defenses be used with a "Sender-Initiated/Unsolicited File
Transfer" system?--probably, but they would not fix the reason for having
such a protocol.  The reason for it now seems to be to hide the unhidable
differences between big and small files and between internal and external
file transfers.


Vernon Schryver    vjs at rhyolite.com