I tested this on my @me.com account, and it's exactly how it works. Email containing the words "barely legal teens" is simply dropped.
I find it obscene to an Orwellian extent that Apple actually seems to think that no valid email would ever contain the words "barely legal teens". I wonder what other things Apple thinks are not worth talking about?
I have no trust in Apple's email services any more.
Microsoft has been doing this for decades. Ever try to collaborate on a web project using MSN Messenger? Every message you sent that contained 'index.php' was mysteriously dropped. It IS Orwellian, but you should not be surprised. The big communication services all seem to have their own little moral or technical hacks they use to keep your discussion limited and away from certain topics / words.
Proprietary IM networks are just that. Email is based on standards, with RFC's defining behavior. Moreover, proprietary IM is based on a some level of membership in that network. Email is open and often involves individuals outside of Apple's iCloud network, users who haven't agreed with Apple to any terms of service or the like.
That's so surprising I tried to find evidence of it online, but I couldn't. Partly because "index.php" is such a common thing that Google won't use it for a search term, which is ironic. Can you point to anything corroborating that?
It is even worse than that -- it also seems to automatically insert graphical smilies whenever it sees what it thinks is a text smiley. Makes it very hard to cut-n-paste a code fragment. Of course you can turn this off, but only on the receiving side -- if you are sending someone a command or piece of code (that contains parentheses and colons), you have know idea if their end will convert to the graphic smilies, and you end up sounding strange to them.
That is not "even worse", that is relatively insignificant. An IM client converting text to smilies by default is standard and easily disabled, or avoided by a different using client.
On the other hand, the issue above represents a horrible failing on the part of MSN as a network/protocol. Silently dropping messages without giving error to either party is insanely stupid behaviour, and MSN's done it frequently for as long as I can remember.
Actually, any mangling of the text is bad. It is bad to drop text, and it is bad to change a line of code to have cartoon graphic images randomly scattered (which you, the sender, don't see but only the receiver does), which makes you look stupid in the eyes of the person receiving it. At least dropping a message makes it look like a network error, the other can make the message sender look like an ignorant fool. (I'm very sensitive to having what I write get changed by something, which is why I absolutely hate auto-correct in a word processor). Both cases have the effect that our corporate-mandated IM client is utterly useless for IT work where you have to send commands or code snippets to others on the team.
No, MSN Messenger did change it for the sender, too. The receiver of a message's settings determined whether they saw the image. You could turn it off in the Text Formatting options, just a simple checkbox.
So I'd disagree with the 'utterly useless' aspect.
That's exactly what I said, if you, the sender, have smilies turned off, you will see the normal code (...:) for example. But if receiver (the person you are sending the message to) doesn't know to turn smilies off, they will receive a graphical picture where the ":)" is in your message, even if it is part of a code block. And there are so many smilies that I don't recognize (not just the ":)" ones), that I never know what the receiver is going to see. Hence, it is useless for sending code fragments (or anything else other than conversational text), since you never know if what is on your screen matches what the receiver will see.
GMail silently drops any emails containing zipped .exe files that I send to my boss. That's despite me being one of his most common correspondents, part of the same GApps domain and whatnot. The problem is the same: spam filtering gone wrong.
wait, you're sending from a google apps domain? From the web interface? It always just refused to send if I've tried to do that in the past, with a message explaining why. If you're sending from a different provider, gmail help claims it will bounce it back, not drop it silently, though I've never actually tried that.
In any case, not allowing specific file types as an attachment feels pretty different here, at the very least because the list of filetypes not allowed are enumerated, the refusal is explicit, and it's not due to the subject of the exe you're trying to send.
I'm sending via a non-Google SMTP server, and there's no bounce message or anything - it's just dropped. I'd argue that silently dropping any message from a known source, regardless of the contents, is wrong. I'd be ok with the -attachment- being removed if a scan shows it's a virus/trojan, but then there should be a notice to both sender and recipient.
Nothing silent about it, in my experience, at least. I was trying to send a self-extracting encrypted archive (full of documents) to my tax guy. Google wouldn't accept the .exe attachment until I added .remove to the end of the name.
The intent is to require the receiver to take some affirmative action (e.g. deleting the .remove) before blindly running the attachment and getting pwned. Seems perfectly reasonable.
Unlike what Apple just got caught doing. I'm ripe for a new phone. I don't think it's going to be an iPhone ...