It just depends on how good your bayes filter is. I agree though that it was much more effective back in the day. Now things like the SURBL are essential. Spammers have to make money some how. To make money they have to get you to buy one of the contract company's products. To get you to buy one of their products/services they have to get you to their website. That's where you nail them. No matter how well they obfuscate the URL you can always figure out what site they're trying to spamertise. Then you just use that as your qualifier for identifying spam. The SURBL is nice.
I used to be a big anti-spammer, back when I had time on my hands. I generated a list of proper-pronouns that was somewhere just over 500k long (I forget the exact #s now). I wrote a number of scripts that used wget and curl (depending on the form) to stuff addresses generated from the pronoun list and about a dozen spam-hole domains I registered into those Remove Me forms. Within hours I was getting tens of thousands of pieces of spam. Within days my Cox cable connection was saturated. I offloaded it onto a co-lo box for another couple of months before I finally changed the MXs to 127.0.0.1 and shut the system down. I had automated scripts for auto-forwarding a copy of the spam to the FTC and to post the messages to NANAS (news.admin.net-abuse.sightings). I also archived the incoming spam and used it to seed my Bayesian filters and DCC system for the ISP I worked for. I can't begin to tell you how effective that was. It was a helluva rig. I wish I still had time to dick around with that kind of stuff.
Hardly. Ralsky was defrauding people with Spamford was sucking his thumb and wearing diapers. I'll simply fall back on the ROKSO. Ralsky has a lengthy entry. Wallace's is all but not existent.
On a side note I checked out SpamHaus's Top Ten and was surprised. I didn't realize how out of touch I've become with the anti-spam effort over the last year or so. I didn't recognize any of the spamming clowns. Too much to do and too little time to screw it up in.
Mid-west actually. And I don't mean some east coast news anchor's idea of Mid-west as being Ohio (pet peeve of mine). Kansas. Most of the towns in our area are relatively small (sub-1000). You do pretty well when you are the only cable TV/Internet/telephone shop in town. The prices are low too, not like someone abusing a monopoly.
That's understandable. This area happens to be a very rural area. Many of the towns in which we own the exchange has 3-400 residents. It's impressive to me that we've managed to offer these rural areas more and better services than most urban counterparts. Imagine getting DSL at a dairy farm 10 miles from town.:-)
You're with entirely the wrong ISP. I've been working for a telco/ISP/consulting company for 11 years now. It started as a telco, started doing PBX installs and consulting at a new branch, and then started offering ISP services in 1995. We service customers more than 10 miles from the CO with Go Digital systems. My parents are 5.5 miles from the CO and 4.5 miles from a paved road. You can do a helluva lot when you're the telco and the ISP. Verizon doesn't give a shit though. They arne't going to invest in a Go Digital system for a dozen customers that won't make any $$ for 5 years. They want to recoup their investment immediately.
We got into one nearby market in which we weren't a LEC by becoming the cable service provider in that town. After we established ourselves with Cable TV we started offering phone service over it. It's extremely reliable, even more so than the incumbent's (Sprint) system. In less than a year we now have over 50% of the home's telephone service in that town. The customers flocked to us in droves. They were sick of being over-charged and under-serviced by Sprint. With us they got local technicians, lower prices, bundled services, reliable phone and Internet, the works. This coming from we're doing the same thing in another 4 towns.
Being a LEC brings with it a lot of authority and IMHO responsibility. It's all in how you wield it.
Alan Ralsky is the grand-daddy of spammers. His past work makes Wallace and friends look like a bunch of chimps tossing shit at one another. The king of spam will always be Alan Ralsky. He pioneered the industry.
His meaning is already quite clear to those of us that manage IP space. Few other people will be able to give him a decent answer on this particular topic.
The Cisco Pix (now ASA) product line are not even distantly related to any LinkSys on the market. Cisco does not make Linksys products. Linksys makes Linksys products. Yes, I'm well aware that Cisco bought Linksys on 3/21/03 but that does not change the fact that Cisco's and Linksys products are not in any way related, yet. There isn't a single product in either company's arsenal that crossover. I work for a Cisco Partner and I with Pixs every day.
That said I'd recommend either a Pix 501 or 506 for a SOHO until Cisco finishes their replacement in the ASA product line. If neither of those devices will fit your needs then I'd recommend stepping up to a x800-series Cisco router. All current Cisco ISR routers have builtin hardware encryption from the basic 850 all the way up to the 3845. Gone are the days of the 2600s which required addon modules. Easy VPN(tm) is quite nice as is the basic IPSec offerings. If you need something even better then step up to a low-end ASA. The ASA 5510 is very nice. The 7.x code on the Pix/ASA line is a major improvement (as is the replacement of the PDM with the ASDM).
I have another method that I prefer. I use passwords that are simply easy to type (ie, something that your fingers will get used to over time). I'm right-handed so I start the password with my left hand. The format is simply 2 numbers, followed by 3 lower-case letters, followed by 3 upper-case letters, followed by the last digit of the sum of the first two numbers. For example:
37cspDUP0
I type the keys with a certain pattern in mind. L = Typed with my Left hand, R = typed with my right hand. In order: LRLLRLRR. More specifically LRLLR press-left-shift-key LRR let-up-left-shift R.
If desired you can use 3-letter acronyms for the characters. You can also put a non-alphanumeric character between the alphanumeric triplets. It's a good place for it because you're already pressing the left shift key.
That's one good password scheme. Phonetics is also good.
Why should they have to? They told the employee numerous times to stop screwing around on the Internet. After multiple warnings they terminated him. What's the problem with that? You repeatedly tell your employee to not do something and they do it anyways. Wouldn't you fire them too? I sure would. I don't pay people to sit on their asses. If you've completed your tasks for the day, aren't on a break, and have nothing else to do pick up a damn broom and sweep the shop floor. There's always something to do.
Except you can not reasonably identify a single customer's IP to make exceptions in your egress filtering. The only reasonable way to do it is to allow all statically assigned customers to run SMTP servers.
Programming can always be transfer overseas. So can call centers, data processing, etc. The only things that can't be outsourced to foreign lands are things that require a physical presence. For example my field is network engineering. You can't mount and wire networking hardware remotely. Same for systems engineering. Someone has to manually mount that server and pull bad drives out of the SAN. That would be my suggestion.
It isn't a horizontal cooler but I do have to say that it's the most impressive cooler I've ever used. I built a dual-Opteron a few months ago and used two of these coolers. Wow. Each CPU runs between 21 and 24 C. That's it. They are also silent. I can not hear them even with the side of my server's case off. I'm thoroughly impressed by these things. They are very large so they won't fit in every case. They did however fit in my Lian-Li 2000 series case. Very nice coolers.
However my test was after my interview and after they offered me the job. It was about 3 hours long and involed 5-6 tests with lots of questions on each. The shrink that gave the test also secretly tested my test instruction following abilities. He would give me the test, give me some superfluous info about the test, then slip in instructions to take the sample questions and stop. Stop was worded differently but the meaning was to stop and no go any further. Then he'd leave you for 15 minutes. The sample tests would only take a minute or 2 and you'd end up sitting there waiting for the guy thinking that you heard that you shouldn't go ahead with the test but questioning whether you're right or not. He'd come in after 15 minutes and pretend like nothing was going on and he'd instruct you to move on with the questions. I saw a small pin-hole camera in the wall behind an large office plant as I was leaving the test room after the test. I wondered if he was watching me but that confirmed it.
Why would you use a host-based ACL to block access to ssh when you can just make ssh listen only on the loopback interface to begin with?
My solution involved running 2 SSH daemons. One accepts all connections on the default port but does not allow root logins. The other allows root logins but can't be remotely accessible. You could run the second daemon bound to localhost. I had a good reason why this wasn't the ideal solution but I forgot it while writing the replies below. Anyhow it's doable but isn't much less effort than running it on tcp/2222 and adding a couple lines to your iptables config.
Also, what good is it to give each user a separate UID 0 account if you have to give them all the "real" root password anyway? Never mind all of the other nuiscances that come up when you have multiple accounts using the same UID...
Why would you give them the root password? My comment didn't say I was giving them the root password. It's not required for all of these users to have the root password, or any of these users for that matter. I've been using this setup for better than 10 years on Solaris and various flavors of Linux (cherry, lemon-lime, marshmallow) and have only found the vlock caveat. Everything else has been smart enough to deal with it. Even the wtmp logs the real userid and not just the first userid associated with a given uid. I don't know if this is a POSIX thing or not but almost everything I've worked with has been written to take this into account. I admit it still surprises me to this day.
Using sudo mitigates all of those problems, while retaining each user's distinct account settings. All the while, it's easier to administer and doesn't require everyone to use the same hacked-up shell.
We haven't actually documented any problems yet. The root password problem is non-existent. The second SSH daemon works either way. vlock isn't really important (and there's numerous patches to resolve the issue anyway). I've used sudo as well. It's nice. I can't think of a large shop that uses it, but it's still nice.
Every single root user in my set up has distinct account settings. They share very little (basically the root mailbox is all). $USER is set to "root" on GNU/Linux. I forget what it is on Solaris. $MAIL feeds off $USER. 'logname' can easily be used to fixed both though, if that's desired which is hasn't ever been in my experience. There isn't any "hacked-up shell" to deal with. The root users can pick from whatever is installed. They're root; they can install the shell of their choosing (if they're willing to face the wrath from me for installing ksh... grrrrr...).
What you've done is like solving the problem of how to automatically shift gears in a car by rigigng up a system of levers and pulleys to a manual gearbox (note, sometimes it won't work, so you have to manually shift), when someone already invented a flawless automatic transmission you could've used instead.:)
It's funny you should mention that. I hate automatic transmissions. They're a waste of steel (now aluminum). I greatly prefer a stick shift. You actually get better mileage with a stick if you know how to shift properly. You could always reprogram your auto with chip that is written with mileage in mind but most are meant for performance. I prefer to control my vehicle and not have some pain in the ass computer do it for me (unless I have control over the computer). My first vehicle was a stick as was the old '65 Jeep truck in which my grandfather taught me to drive. That wagon is the closest photo I can find of the old Jeep. The front end is the same as is the interior (red). I can't find a photo of a real '65 truck though. We still have the Jeep.
Back on topic. Sudo and this SSH solution are both good. Both have their uses. If I have a set of users that I want to only have access to certain comamnds then I'll use sudo (or write a nice shell wrapper). However if I have a sysadm that nee
I know a security nut that simply stores his RSA keys on an encrypted thumb drive. Whenever he walks away from his computer he pulls the thumb drive. Slick. He plugs it back in when he returns and authenticates to decrypt his thumb drive file system.
Create multiple UID 0 users (one per root-privileged sysadmin). Compile Bash w/ syslog support. Point your syslog @ a remote syslog machine. Piece of cake. This has numerous advantages IMHO. It gives each user their own shell history. Every user has their own shell environment (PS1, PATH, etc). It gives all the root users access to common root mailbox. I will warn you though that vlock is not smart enough to deal with this setup. A user will still have to use the password of the main "root" user to unlock the shell after using vlock.
I know some large Solaris shops that give admins (senior and junior admins) root privs by simply adding their SSH RSA public key to root's authorized_keys(2) file. Then the admins can "ssh THEIRROOTUSERID@localhost" to get root privs. Ideally you'd prohibit remote root SSH access. To work around this run SSH on a non-standard port and use a host-based ACL to restrict access to that port to only localhost. Whenever they need to revoke root privs the administration simply remove the person's public key. No one ever needs to know root's password this way. No one needs to memorize a new password everytime a person's root privs get revoked. The same vlock problem applies here too.
I use both method. In fact I tend to use both method together. I create a UID 0 user for each of my admins. I use the SSH key trick for getting my admins logged into those root-privileged accounts. I use a simple.bash_logout script that archives the current history output to a timestamped file. I use the SYSLOG patches on a custom install of Bash. It's quite a slick system.
Aren't they encrypted? My current phone (Verizon XV6700) has an option in the wireless services menu called "Voice Privacy". My really old Nokia 6120i also had this option. I think my Nokia 638 had the same option as well. If that service isn't about encryption then does anyone know what it's for?
We have come far. However your order of encapsulation steps is a bit off.
The application data is packaged into the 1472-byte payload of a TCP/IP packet. That TCP/IP packet is handed off to the network interface adapter. For this example lets assume it's an Ethernet nic. The Ethernet nic (its driver or the actual ASIC on a fancy server nic) encapsulates the TCP/IP packet and stuffs it in the 1500-byte payload of an Ethernet frame (again we're glossing over the possibility of jumbo frames). Lets gloss over all of the network stuff between your nic, your LAN switch, your core router, and your WAN router (and everything else in between, assuming of course that your LAN is entirely composed of Ethernet-based technologies). Your WAN router will accept the Ethernet frame on an Ethernet-based interface. The ASICs deconstruct the Ethernet frame to extract the TCP/IP packet inside. The TCP/IP packet's header give the WAN router the destination IP address of the TCP/IP packet. Gloss over the routing decision process. Also for simplicity's sake lets assume that your router connects to the Internet via one of a couple dozen methods that involve ATM. The WAN router now takes the TCP/IP packet and fragments it, stuffing the fragments into 53-byte ATM cells (48-byte payload). Toss in some POS, MPLS, etc, etc, yadda, yadda. And finally you more or less reverse these steps for the remote end. Again, we're glossing over a lot here. This is a little more technically accuratee than your summarization. The only time that I can recall Ethernet frames being fragmented and stuffed into ATM cells (complete with the Ethernet frame's payload contents) is some implementations using LANE.
But yes it is impressive how far things have come.
I was 7 or 8 in a very small rural town with nothing to do. That's the norm. I was too small to haul hay and the town was too small to support a mowing service. What else are you going to do in a town of 200 people in the middle of a 100+ degree summer but make mud pies, fry worm, boil frogs, and go fishing?
I have the absolute best method for disposing of CC apps. I don't tear them up, shred them or burn them. I line the bottom of my cats' litter box with my CC apps. The way I see it if someone jackass wants to dig through my cats' crap then he earned my disposed-of app. The CC companies also deserve to get a really stained and smelly app in the mail.
Slashdot Mirror
It just depends on how good your bayes filter is. I agree though that it was much more effective back in the day. Now things like the SURBL are essential. Spammers have to make money some how. To make money they have to get you to buy one of the contract company's products. To get you to buy one of their products/services they have to get you to their website. That's where you nail them. No matter how well they obfuscate the URL you can always figure out what site they're trying to spamertise. Then you just use that as your qualifier for identifying spam. The SURBL is nice.
I used to be a big anti-spammer, back when I had time on my hands. I generated a list of proper-pronouns that was somewhere just over 500k long (I forget the exact #s now). I wrote a number of scripts that used wget and curl (depending on the form) to stuff addresses generated from the pronoun list and about a dozen spam-hole domains I registered into those Remove Me forms. Within hours I was getting tens of thousands of pieces of spam. Within days my Cox cable connection was saturated. I offloaded it onto a co-lo box for another couple of months before I finally changed the MXs to 127.0.0.1 and shut the system down. I had automated scripts for auto-forwarding a copy of the spam to the FTC and to post the messages to NANAS (news.admin.net-abuse.sightings). I also archived the incoming spam and used it to seed my Bayesian filters and DCC system for the ISP I worked for. I can't begin to tell you how effective that was. It was a helluva rig. I wish I still had time to dick around with that kind of stuff.
On a side note I checked out SpamHaus's Top Ten and was surprised. I didn't realize how out of touch I've become with the anti-spam effort over the last year or so. I didn't recognize any of the spamming clowns. Too much to do and too little time to screw it up in.
Mid-west actually. And I don't mean some east coast news anchor's idea of Mid-west as being Ohio (pet peeve of mine). Kansas. Most of the towns in our area are relatively small (sub-1000). You do pretty well when you are the only cable TV/Internet/telephone shop in town. The prices are low too, not like someone abusing a monopoly.
That's understandable. This area happens to be a very rural area. Many of the towns in which we own the exchange has 3-400 residents. It's impressive to me that we've managed to offer these rural areas more and better services than most urban counterparts. Imagine getting DSL at a dairy farm 10 miles from town. :-)
We got into one nearby market in which we weren't a LEC by becoming the cable service provider in that town. After we established ourselves with Cable TV we started offering phone service over it. It's extremely reliable, even more so than the incumbent's (Sprint) system. In less than a year we now have over 50% of the home's telephone service in that town. The customers flocked to us in droves. They were sick of being over-charged and under-serviced by Sprint. With us they got local technicians, lower prices, bundled services, reliable phone and Internet, the works. This coming from we're doing the same thing in another 4 towns.
Being a LEC brings with it a lot of authority and IMHO responsibility. It's all in how you wield it.
Alan Ralsky is the grand-daddy of spammers. His past work makes Wallace and friends look like a bunch of chimps tossing shit at one another. The king of spam will always be Alan Ralsky. He pioneered the industry.
His meaning is already quite clear to those of us that manage IP space. Few other people will be able to give him a decent answer on this particular topic.
That said I'd recommend either a Pix 501 or 506 for a SOHO until Cisco finishes their replacement in the ASA product line. If neither of those devices will fit your needs then I'd recommend stepping up to a x800-series Cisco router. All current Cisco ISR routers have builtin hardware encryption from the basic 850 all the way up to the 3845. Gone are the days of the 2600s which required addon modules. Easy VPN(tm) is quite nice as is the basic IPSec offerings. If you need something even better then step up to a low-end ASA. The ASA 5510 is very nice. The 7.x code on the Pix/ASA line is a major improvement (as is the replacement of the PDM with the ASDM).
37cspDUP0
I type the keys with a certain pattern in mind. L = Typed with my Left hand, R = typed with my right hand. In order: LRLLRLRR. More specifically LRLLR press-left-shift-key LRR let-up-left-shift R.
If desired you can use 3-letter acronyms for the characters. You can also put a non-alphanumeric character between the alphanumeric triplets. It's a good place for it because you're already pressing the left shift key.
That's one good password scheme. Phonetics is also good.
Why should they have to? They told the employee numerous times to stop screwing around on the Internet. After multiple warnings they terminated him. What's the problem with that? You repeatedly tell your employee to not do something and they do it anyways. Wouldn't you fire them too? I sure would. I don't pay people to sit on their asses. If you've completed your tasks for the day, aren't on a break, and have nothing else to do pick up a damn broom and sweep the shop floor. There's always something to do.
Except you can not reasonably identify a single customer's IP to make exceptions in your egress filtering. The only reasonable way to do it is to allow all statically assigned customers to run SMTP servers.
Programming can always be transfer overseas. So can call centers, data processing, etc. The only things that can't be outsourced to foreign lands are things that require a physical presence. For example my field is network engineering. You can't mount and wire networking hardware remotely. Same for systems engineering. Someone has to manually mount that server and pull bad drives out of the SAN. That would be my suggestion.
http://www.thermaltakeusa.com/product/cooler/retai l/cl-p0114/cl-p0114.asp
However my test was after my interview and after they offered me the job. It was about 3 hours long and involed 5-6 tests with lots of questions on each. The shrink that gave the test also secretly tested my test instruction following abilities. He would give me the test, give me some superfluous info about the test, then slip in instructions to take the sample questions and stop. Stop was worded differently but the meaning was to stop and no go any further. Then he'd leave you for 15 minutes. The sample tests would only take a minute or 2 and you'd end up sitting there waiting for the guy thinking that you heard that you shouldn't go ahead with the test but questioning whether you're right or not. He'd come in after 15 minutes and pretend like nothing was going on and he'd instruct you to move on with the questions. I saw a small pin-hole camera in the wall behind an large office plant as I was leaving the test room after the test. I wondered if he was watching me but that confirmed it.
My solution involved running 2 SSH daemons. One accepts all connections on the default port but does not allow root logins. The other allows root logins but can't be remotely accessible. You could run the second daemon bound to localhost. I had a good reason why this wasn't the ideal solution but I forgot it while writing the replies below. Anyhow it's doable but isn't much less effort than running it on tcp/2222 and adding a couple lines to your iptables config.
Also, what good is it to give each user a separate UID 0 account if you have to give them all the "real" root password anyway? Never mind all of the other nuiscances that come up when you have multiple accounts using the same UID...
Why would you give them the root password? My comment didn't say I was giving them the root password. It's not required for all of these users to have the root password, or any of these users for that matter. I've been using this setup for better than 10 years on Solaris and various flavors of Linux (cherry, lemon-lime, marshmallow) and have only found the vlock caveat. Everything else has been smart enough to deal with it. Even the wtmp logs the real userid and not just the first userid associated with a given uid. I don't know if this is a POSIX thing or not but almost everything I've worked with has been written to take this into account. I admit it still surprises me to this day.
Using sudo mitigates all of those problems, while retaining each user's distinct account settings. All the while, it's easier to administer and doesn't require everyone to use the same hacked-up shell.
We haven't actually documented any problems yet. The root password problem is non-existent. The second SSH daemon works either way. vlock isn't really important (and there's numerous patches to resolve the issue anyway). I've used sudo as well. It's nice. I can't think of a large shop that uses it, but it's still nice.
Every single root user in my set up has distinct account settings. They share very little (basically the root mailbox is all). $USER is set to "root" on GNU/Linux. I forget what it is on Solaris. $MAIL feeds off $USER. 'logname' can easily be used to fixed both though, if that's desired which is hasn't ever been in my experience. There isn't any "hacked-up shell" to deal with. The root users can pick from whatever is installed. They're root; they can install the shell of their choosing (if they're willing to face the wrath from me for installing ksh... grrrrr...).
What you've done is like solving the problem of how to automatically shift gears in a car by rigigng up a system of levers and pulleys to a manual gearbox (note, sometimes it won't work, so you have to manually shift), when someone already invented a flawless automatic transmission you could've used instead. :)
It's funny you should mention that. I hate automatic transmissions. They're a waste of steel (now aluminum). I greatly prefer a stick shift. You actually get better mileage with a stick if you know how to shift properly. You could always reprogram your auto with chip that is written with mileage in mind but most are meant for performance. I prefer to control my vehicle and not have some pain in the ass computer do it for me (unless I have control over the computer). My first vehicle was a stick as was the old '65 Jeep truck in which my grandfather taught me to drive. That wagon is the closest photo I can find of the old Jeep. The front end is the same as is the interior (red). I can't find a photo of a real '65 truck though. We still have the Jeep.
Back on topic. Sudo and this SSH solution are both good. Both have their uses. If I have a set of users that I want to only have access to certain comamnds then I'll use sudo (or write a nice shell wrapper). However if I have a sysadm that nee
I know a security nut that simply stores his RSA keys on an encrypted thumb drive. Whenever he walks away from his computer he pulls the thumb drive. Slick. He plugs it back in when he returns and authenticates to decrypt his thumb drive file system.
I know some large Solaris shops that give admins (senior and junior admins) root privs by simply adding their SSH RSA public key to root's authorized_keys(2) file. Then the admins can "ssh THEIRROOTUSERID@localhost" to get root privs. Ideally you'd prohibit remote root SSH access. To work around this run SSH on a non-standard port and use a host-based ACL to restrict access to that port to only localhost. Whenever they need to revoke root privs the administration simply remove the person's public key. No one ever needs to know root's password this way. No one needs to memorize a new password everytime a person's root privs get revoked. The same vlock problem applies here too.
I use both method. In fact I tend to use both method together. I create a UID 0 user for each of my admins. I use the SSH key trick for getting my admins logged into those root-privileged accounts. I use a simple .bash_logout script that archives the current history output to a timestamped file. I use the SYSLOG patches on a custom install of Bash. It's quite a slick system.
So do hunters and soldiers. One eye stays on the target and the other is lined up with the sites or optics.
Aren't they encrypted? My current phone (Verizon XV6700) has an option in the wireless services menu called "Voice Privacy". My really old Nokia 6120i also had this option. I think my Nokia 638 had the same option as well. If that service isn't about encryption then does anyone know what it's for?
The application data is packaged into the 1472-byte payload of a TCP/IP packet. That TCP/IP packet is handed off to the network interface adapter. For this example lets assume it's an Ethernet nic. The Ethernet nic (its driver or the actual ASIC on a fancy server nic) encapsulates the TCP/IP packet and stuffs it in the 1500-byte payload of an Ethernet frame (again we're glossing over the possibility of jumbo frames). Lets gloss over all of the network stuff between your nic, your LAN switch, your core router, and your WAN router (and everything else in between, assuming of course that your LAN is entirely composed of Ethernet-based technologies). Your WAN router will accept the Ethernet frame on an Ethernet-based interface. The ASICs deconstruct the Ethernet frame to extract the TCP/IP packet inside. The TCP/IP packet's header give the WAN router the destination IP address of the TCP/IP packet. Gloss over the routing decision process. Also for simplicity's sake lets assume that your router connects to the Internet via one of a couple dozen methods that involve ATM. The WAN router now takes the TCP/IP packet and fragments it, stuffing the fragments into 53-byte ATM cells (48-byte payload). Toss in some POS, MPLS, etc, etc, yadda, yadda. And finally you more or less reverse these steps for the remote end. Again, we're glossing over a lot here. This is a little more technically accuratee than your summarization. The only time that I can recall Ethernet frames being fragmented and stuffed into ATM cells (complete with the Ethernet frame's payload contents) is some implementations using LANE.
But yes it is impressive how far things have come.
I was 7 or 8 in a very small rural town with nothing to do. That's the norm. I was too small to haul hay and the town was too small to support a mowing service. What else are you going to do in a town of 200 people in the middle of a 100+ degree summer but make mud pies, fry worm, boil frogs, and go fishing?
As a little kid I actually tried put this myth to the test it worked flawlessly.
I have the absolute best method for disposing of CC apps. I don't tear them up, shred them or burn them. I line the bottom of my cats' litter box with my CC apps. The way I see it if someone jackass wants to dig through my cats' crap then he earned my disposed-of app. The CC companies also deserve to get a really stained and smelly app in the mail.
That's called libel. We don't need another law to enforce that.