At your home, you most likely access the internet using a 56K modem - or even better yet, you're connected to the internet via a cable modem. In either case, you are VERY fortunate when compared to the ship. In the worst case (if you're using a 56K modem), you have that entire 56K of bandwidth all to yourself - for email, or browsing, or whatever you like to do on the internet. That's a HUGE "pipe" when compared to what's available to the sub. The sub has less than 3K and that small "pipe" has to support not only all of the email for every person onboard (inbound and outbound), but also any tactical information coming in via that path. The bottom line is that with such a small "pipe" available with which to receive data (including email), we're forced to fight (and fight very hard) to ensure that we safeguard the data / information going down that "pipe" to ensure that not only everyone gets their email, but that the ships tactical traffic gets delivered. There's simply no room to spare.
So.... Here's what we do.....
1. We limit the size of all messages going to the ship to 15K. This usually isn't an issue, since the average email ranges in size from 2K - 5K. Unless someone gets VERY verbose, this limit is only rarely exceeded. A rough rule of thumb is that a reasonable sized paragraph is 1K - which means you're able to send approximately a 15 paragraph email. If the limit is exceeded, the message is rejected as being too large, and the sender is notified what that size limit is in the rejection notice. When the email is rejected, in addition to the rejection notice, the entire original email is sent back to the originator.
We are also forced to eliminate all attachments. While we'd love to be able to support sending graphics and any other attachments, there's simply no "room" for that in the small pipe. As a result, we're unable to forward attachments, such as photo's, movies, documents, and the like, to the ship. You might think that regardless how small the "pipe" is, if the sub receives the data for a long enough period, even large files will eventually get onboard. That's not correct in this case, since the submarine is also limited in the time it's able to stay at communications depth. The end result is that even if large files (i.e. attachments) were permitted, the limited time available to download these files would preclude our ability to get them onboard. As a result, if the system detects an attachment, the text of the email is sent but without the attachment, and a "flag" is set. I'll explain the "flag" below - but it's important, so please keep it in mind.
Some people attempt to forward email from some other person, to the
person on the ship. When this happens, its common practice for the originators email system to precede each line with ">". This signifies that the data to the right is "forwarded" data, and not information originated from the sender. Consider what happens if the sailor sends you an email.... and if you simply reply to that email. In this case the sailors original email would still exist at the bottom of this "new" email, with his lines preceded with ">". We don't want to take up precious bandwidth by simply sending back to the sailor the same stuff he sent you, so when an email gets forwarded to the sub, the process looks for all lines which begin with ">", and removes them. As those lines are removed, they're also counted, and a note is appended to what the sailor will receive, to indicate that "forwarded" lines have been removed from the original copy. Since the sailor will not be receiving EXACTLY what was sent from the originator, the "flag" gets set - just as above.
4. This is the most common reason for people receiving those "modified" messages. Some mail systems forward the EXACT SAME INFORMATION in different formats. For example, if you send someone an email, unknown to most folks, is that many mail systems send the entire contents in text format, and then again in rich text format, and then again in HTML format - all in the same email. The impact is that the exact same information can get forwarded three times, each time in a different format - and all in the same email. I think most would agree that only one instance is needed, so the
October 9 – October 15, 2006