Spam from Coffee shops?

Bruce Schneier, one of my heroes, wrote that he runs an open WiFi at his home. One of his reasons was:

I can count five open wireless networks in coffee shops within a mile of my house, and any potential spammer is far more likely to sit in a warm room with a cup of coffee and a scone than in a cold car outside my house.

I run my own mail server at home, and originally configured it to accept the STARTTLS command. Running an open relay is a no-no, and so unless you have authentication credentials, connecting to my server from outside will only allow local delivery. With the credentials, you can send mail to anywhere.

One day soon after configuring this, I was sitting in a local coffee shop (I think it was Caribou, but I am not sure), sending an e-mail and got a strange error message: it didn't recognize the STARTTLS command. After a few minutes head scratching trying to understand why my server wasn't recognizing it, I realized that I wasn't connecting to my home server. The coffee shop wireless (on top of their auto-sign-in process) was stealing all port 25 traffic and feeding it to their own server. I'm just guessing, but I'd bet a lot that this is to prevent someone from walking in, grabbing a delicious cup of coffee and a scone, and sending a few thousand e-mails saying "Dearest one, I am a 200 year old senile senior citizen who wants to give you a 25,123,999 (twenty five million, one hundred twenty three thousand, nine hundred ninety nine) U. S. Dollars".

I began running a second mail server on a different port, and now it works fine. Port 25 is still for anyone sending me mail (including, unfortunately, spammers) and the other port is for me when I'm away from home.

One of the reasons I set up my own mail server was security: checking e-mail is done via secure IMAP, sending is done via encrypted SMTP, and theoretically, I can send myself a message and later read it, from anywhere in the world, securely. I don't have anything that really requires that much security, but it's cool to have it.

And yet, it's not perfect. A coffee shop/hot spot could run a man-in-the-middle attack by carefully watching my outgoing traffic, and if I'm not careful about certificates, they've got me. I'm not sure why they'd want to, but it's possible.

Embrace and Extend or Standardize and Stultify

The operator precedence in the title is correct: and binds tighter than or.

I've long been a fan of the GNU compiler (since at least the early 90s), but I'm a little disappointed with their current direction.

Let's say you wanted a C++ class for string handling. We'll just put in a char * member variable (the only data member) and some cool functions like Left, Capitalize, Parse and Rot13 (also known as SuperSecretEncryption).

class CString {
public:
 CString Left(int NumberCharacters);
 void Capitalize();
 int Parse(char *Format, ...);
 void Rot13();
private:
 char *m_Data;
};

A cool thing to do with strings like this is to pass them to printf:

CString MyString;
...
printf("Here it is: <%s>\n", MyString);
...

Should this work? Consider:

char *foo; printf("%s", foo);

The arguments to printf are a pointer to a string, and a pointer to a string. Now, for the MyString printf, the first argument is still a pointer to a string. The second is an object, and what actually gets put on the argument list is the contents of the object, which is, you guessed it, a pointer to a string.

So it should work. And it does with Microsoft's Visual C++ compiler (which is where I happened to meet this idiom).

However, the GNU C++ compiler complains with this message:

cannot pass objects of non-POD type 'CString' through '...'

If you take a look at this thread in the GNU C++ compiler mailing list, you'll see that it is not supported, because it is not standard. Worse, the compiler, in pursuit of standardness, does not issue an error message, and instead emits code causing the program to abort.

That's right: they print a warning, and if you ignore the warning and run the program: CORE DUMP. A little unfriendly...

The Intel C++ compiler does better, it prints a warning but emits code to do the right thing.

While Microsoft is often guilty of Embrace and Extending common standards (such as HTML so that web pages only correctly display in Internet Explorer), in this case I don't think they've done anything wrong. The metaphor is very useful, and there is no benefit to forcing programmers to use the clumsier:

printf("%s", (char *)MyStringObject);

(assuming that there is a conversion operator for CStrings).

The GNU compiler group is guilty of an equally evil technique: let's call it "Standardize and Stultify". When I pointed out that the metaphor was useful, I received the terse reply:

> The class is a non POD.

Meaning basically "we're sticking to the standard, broken though it may be".

The Intel compiler got it right, but of course this would tie me to Intel and AMD platforms.