nanog mailing list archives
The attachment mess, was w32/bagle
From: David Lesher <wb8foz () nrk com>
Date: Fri, 5 Mar 2004 09:29:33 -0500 (EST)
Speaking on Deep Background, the Press Secretary whispered:
pass. I will be the first to admit that using mail as a file transfer protocol isn't the way to go, but getting people to realize that (and forcing them to change) is next to impossible.Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this. Curtis
I've pipedreamed a scheme that would do this: Sending Luser drops file on to Attached File line in the MUA {say, Eudora} and Sends. MUA opens https to its own MTA/server, encrypts & uploads file and designates file name. It puts the unique URL/key into the pseudo-Attachment line of the mailer. [Attachment's encrypted so that if the mail itself is, the file would not be lesser-protected. Real security would require the MUA, not the MTA to do encryption, I guess] Receiving Luser (RL) gets message with Attachment link. {S}he clicks on it, not really knowing/caring it is a https link. Decrypted "attachment" is dumped on RL's desktop. Behind the scenes, the Sending MTA notes the file was grabbed. It has a set of expiration rules, whatever its local policy is -- X days if not yet grabbed one, Y days after the first, -- & a history file al-la Usenet spool. SMTA expires old messages. The advantage to the MTA operators is no longer will people try to cram 35 MB Powerpoint files down mail pipes. Yes, they are stuck storing the files for a few days, and moving later; but ?some? will never be moved at all, saving BW. {The old "what's cheaper, disk or pipe?" issue arises here.} Further, "Attachment" transfer BW could be QOS'ed downscale. Variations might be the file is not stored by the SendingMTA but pushed to the ReceivingMTA/MX. Or when the RL "opens" mail, it's moved from SMTA to RMTA/MX, and then to the RL. I'd have thunk someone already thought of all this, but I've not seen such discussed. Even a clueless guy like me can see there are multiple reasons It Won't Fly, some perhaps solvable. a) Gripe: Attached Files would expire. Someone Would Complain. Response: BFD. Tell the sender to "mail that file again.." b) G: Mail Systems operators are stuck storing files & must run expiration scripts. R: And this is worse than the terrabytes now being queued? Plus, space could be limited and maybe chargeable. c) G: Critical Mass needed before it can be usable at all. You'll never ever get there unless Billy puts it into LookOut^H^H^HOutlook. R: Yea. In order to crack c); I guess it would take not just a solid RFC and running code; but a 900# Gorilla demanding such, maybe Earthlink or AOL. Flaming session is now open. I'm not awake yet, so I plead the Hypnos Defense. -- A host is a host from coast to coast.................wb8foz () nrk com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
Current thread:
- Re: dealing with w32/bagle, (continued)
- Re: dealing with w32/bagle Curtis Maurand (Mar 04)
- Re: dealing with w32/bagle Sam Stickland (Mar 05)
- One hint - how to detect invected machines _post morten_... Re: dealing with w32/bagle Alexei Roudnev (Mar 05)
- Re: dealing with w32/bagle Valdis . Kletnieks (Mar 05)
- Re: dealing with w32/bagle Richard Welty (Mar 05)
- Re: dealing with w32/bagle Roland Perry (Mar 04)
- Re: dealing with w32/bagle Stephen Milton (Mar 04)
- Re: dealing with w32/bagle Curtis Maurand (Mar 04)
- Message not available
- Re: dealing with w32/bagle JC Dill (Mar 05)
- Re: dealing with w32/bagle Jeff Shultz (Mar 05)
- The attachment mess, was w32/bagle David Lesher (Mar 05)