Let's just agree to disagree, shall we? We're both right as far as it goes--you have the most elegant solution, I have the quick and dirty solution. Both are partly right and partly wrong, mine because there's abuse, yours because it's a hassle beyond the worth of most attachments and dependent on the charity of others. But please remember that not all attachments are evil--some of them are at least benign, if not good.
On Tue, 6 Apr 1999, Gary Singleton wrote: > --- John Galt <[EMAIL PROTECTED]> wrote: > > On Sun, 4 Apr 1999, Gary Singleton wrote: > > > > > --- John Galt <[EMAIL PROTECTED]> wrote: > > > > > > > > What's the accepted method of sending a file to > > a > > > > person that MUST not > > > > get into unfriendly hands, but needs to get > > between > > > > users that have no > > > > access to the other's machine, due to dynamic > > PPP > > > > and hostile ISPs, then? > > > > > > Dynamic IP addresses can be taken care of using > > > services like dyndns.org, ddns.org & many others. > > My > > > machine is online several hours a day using > > dyndns, I > > > have the proftpd server running and can allow > > secure > > > access via this or even using Apache. If I was to > > > have such a "hostile ISP" I would switch to one of > > the > > > many available in most areas of the world. Many > > ISPs > > > however might be considered "hostile" by newbies > > for > > > not allowing large attachments or charging for > > excess > > > mail storage. > > > > So what you're proposing instead of large > > attachments to email is for the > > end user to set up two different services and quite > > possibly change their > > ISP. While we're at it, what else do you want to > > make into a major > > headache so you don't have to use procmail? I've > > got it, let's rewrite > > TCP/IP so that no more than 1KB of packets may be > > transmitted between > > peers without authentication, that oughta make you > > EXTREMELY pleased. > > Yes, my provided alternatives to solve your original > "problems" were to get a dyndns.org account and set up > an ftp server. It's really not that difficult and is > much more convenient. The recipient is notified of > the file and is able to retrieve it at his > convenience. FTP (not anonymous) is at least as > secure as email so that part is also taken care of. I > shouldn't have to change my email setup to compensate > for others inconsiderate behavior. Also, if I had > what I considered a hostile ISP, you bet I'd find a > new one. As to rewriting TCP/IP, I'm the one trying > to stay within accepted protocol; you are advocating > bending or rewriting the rules to legitimize your > methods. > > > > > This method should be as easy and as > > transportable > > > > as POPmail, not > > > > involve other servers in any way save routing, > > be > > > > able to be used > > > > internationally, and ensure delivery to only the > > > > intended person. > > > > > > Why, just to bend the rules to your definition of > > what > > > the method "should be"? That's a little like > > saying > > > "I'm now using the internet, you must all bend to > > my > > > definition of what e-mail should be". > > > > No, I was describing the basis of sending a large > > attachment via > > email--POPmail, the only servers in use are > > temporarily the routing hosts > > and the ends, and relatively secure delivery--there > > are ways to intercept > > email, but there are also ways to intercept ALL > > TCP/IP packets with a > > similar amount of work. So my "bend[ing] the rules" > > is no more than > > telling you that something has to be as useful as > > all other > > alternatives before it can be unequivocally the > > right way. > > The reason I brought up security of email the first > time was to make you aware that it is no more secure > than other methods just because it is destined to a > specific recipient. > > > > > Give > > > > up? Well so do I. Solve this problem before you > > > > beef about how large > > > > attachments to email is evil. > > > > > > You can give up if you like, but I'll continue to > > take > > > the position that e-mail is for message exchange > > not > > > file exchange. There are established methods for > > > secure file transfer & by the way, e-mail is most > > > definitely not the most secure method of transfer > > for > > > any file that "MUST not get into unfriendly > > hands". > > > > Most crypto is based on a similar setup to email, > > and your established > > methods don't mean anything without citation, which > > is what I asked for in > > the first place. It's true that email is for > > message exchange, but what > > happens when the message happens to be a chapter of > > a book with formatting > > intact? Your broad stroke of "no large attachments > > to email" just nuked > > collaborative publishing, as my stepfather (when he > > was co-authoring > > his textbook) emailed revisions to chapters of his > > book, which he said was > > the accepted standard in the publishing community (I > > didn't really care > > much about the whys and wherefores when he did > > it--he and I have semi > > strained relations at best). > > The encryption issue has already been addressed as > well as my solution for your problems. To summarize: > dyndns.org, proftpd, new ISP. There are document > control systems that would be much better for writing > a book than emailing chapters to one another. I've > used Lotus Notes (admittedly not a Linux product) in > the past for exactly this function. My "broad stroke" > wouldn't nuke anything, it would however force the > adoption of a better method. I would have expected > the "publishing community" to have developed something > a little more advanced - surprising. > > > > I will continue to beef about large attachments > > when > > > they are sent to me and mine unrequested & > > unwelcome. > > > There are solutions available if you would look, > > > perhaps they're not as "easy and transportable" > > but > > > they are there, they are established and they are > > the > > > proper way of handling large file transfer, secure > > or > > > not. > > > > So what you're trying to say is that you really > > don't need to provide > > citation when asked--I guess they really are secure > > methods if their > > existence isn't able to be promulgated. I asked a > > question, and all I got > > from you is a load of unfinished descriptions and > > glittering generalities. > > When you can come up with some concrete examples, > > please continue, until > > then please crawl back under the rock you came from. > > <CITATION> > dyndns.org to eliminate the dynamic IP problem. > proftpd to provide "file transfer protocol" service. > New ISP if yours is "hostile". > Lotus notes for document revision control. > </CITATION> > > I really enjoyed your last sentence, it's nice to see > that your rude, inconsiderate behavior doesn't stop > with sending large e-mail attachments. How about some > name calling next time? <BG> > > G.S. > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null > Artificial intelligence is no match for natural stupidity. Who is John Galt? [EMAIL PROTECTED], that's who!
