Not sure what to say. For my own mail, I create a new address whenever I give out my email: either base+foo@example.com or foo@mydomain.com where "foo" can be any string which is only used once and procmailed if sold. This is 100% effective and is done automatically (eg, I don't have to edit an alias file or such, anything will get to me). When posting an address to the web, I use javascript obfuscation so the bots won't get it.
I only do mail for one small group of (non-technical) people and I don't do anything spam-wise for them (other than the base+suffix trick) since they haven't asked and I don't have time. The most I would do if asked is to install spamassassin or similar or go with a very conservative blacklist. I've seen njabl used and it catches a lot of spam without raising a lot of legitimate complaints. They classify hosts, so you can, for instance, block open relays and open proxies but allow through dynamically-assigned dialup IPs if needed. However, I wouldn't do any tricks like requiring valid originating MXes or even doing reverse DNS lookups on incoming IPs since I don't want to deal with the support issues.
I don't know how to make spam go away for good. I'm also not motivated to do a lot of thinking or experimentation on the problem since the base+suffix trick eliminated all my spam.
If each domain holder paid an additional $2/year for renewal, this would generate more than $50 million for cybercrime enforcement activities. If each domain holder paid $5/year, that would generate more than $1.3 BILLION DOLLARS
So when my mail server gets a connection from an IP, it notes it, then it does an MX lookup on the alleged MAIL FROM. If the connecting IP isn't an MX for the MAIL FROM, my server marks it as spam.
Consider this: I need to send work-related mail from home. My ISP, in an effort to stop spam, only allows their outgoing mail server to handle mail where FROM is one of their addresses. I can no longer send work-related mail from home to you.
Now I'm not particularly interested in "workarounds" since this is not a problem for me personally (I avoid graphical mail clients). Consider that it's a real problem for a large number of people whose companies don't have VPNs and who do not have the skill or motivation to set up ssh tunelling or some other kind of tunnel. It's also an inconvenience for people like me that have multiple addresses in multiple domains who would have to hack their MUA to recognize (based on from address) which outgoing mail server to use (and how to set up a tunnel to that server if necessary).
If you're doing this to deal with your own personal mail, then go for it. However, you may want to reconsider before implementing this for some company or group of people.
You are using netinfo on MacOS X Server 10.2 to authenticate clients remotely. This is a bad idea; anyone on a network served by your netinfo server can obtain the password hashes on all accounts and then run a cracker against them. Basically, this is like broadcasting your password file to the world.
To demonstrate: on any of your clients, type "niutil -readprop -t server_ip/network/users/username/passwd"
Substitute "username" with any username or read all the usernames. Hell, I'll script it for you:
#!/bin/sh IP=your_ip DB=your_db niutil -list -t $IP/$DB/users | while read i u do echo -n $u: niutil -readprop -t $IP/$DB/users/$u done
The hashes are encrypted using the standard Unix crypt(3). You can then massage them into some format that Crack can read and let it go. Remember, any user with access to your network can do this.
I really thought it was quite irresponsible of Apple to release this software and recommend this configuration to users. It took them a good long time to fix it.
Panther (client) finally fixed this. You'll note that passwords are no longer stored in netinfo, but netinfo rather references a "guid" which in turn references a file that stores the password, readable only by root. This means that standalone Macs no longer give all users access to all password hashes. I understand netinfo will finally be fully deprecated in 10.3 server.
You also asked if anyone has had other problems with MacOS X Server: I would strongly recommend against their mail server software. It does finally store messages as discrete files on the filesystem, so some munging can be fixed, but message flags are still stored in some opaque binary format that tends to get corrupted. In fact, whenever 10.2 server goes down ungracefully, all flags on messages are corrupted on our mail server, and thousands of deleted (and purged) messages re-appear in all the inboxes. The particular machine is on a UPS, so this doesn't happen very often, but it happens whenever the machine is purposefully rebooted without first explicitly stopping the mail server.
The good thing about 10.2 server is that it stores the passwords using standard DES crypt(), which makes migrating from it very easy. A shell script like the one above can produce a password file readable by most any *nix flavor. 10.3 uses some bizaare format that I can't readily identify. Since a lot of the most important bits of MacOS are closed-source, you may have a very difficult time migrating away from 10.3 server if it uses something akin to the 10.3 client hashes (options are making all users create new passwords or spending lots of time reverse-engineering the hash and writing an equivalent pam module for another OS (I'm assumming this new hashing stuff is not in Darwin, as most things in MacOS where I needed the code were not in Darwin - but I haven't checked for this)).
Anyway, your best bet is to drop netinfo and start using LDAP. MacOS X (client and server) uses OpenLDAP, which doesn't have these security issues, is easy to migrate onto other OSes, and is open source (with no modifications that I can identify), so you at least have the ability to fix your own problems if you're not scared of some coding. For example, the OpenLDAP version that ships with MacOS X 10.2 has a bug in that TLS_CACERTDIR directive does not work. I was able to identify and work around this since I had access to the code.
The hard disk bracket is connected with one very small low-profile philips screw in an awkwardly-placed recessed counter-sunk hole.
I've stripped a number of these screws. I've taken to moving the hard disk from the bottom position in the bracket to the top position so the screw could be replaced with a standard screw with a deeper head.
Past that, I have no complaints about the b/w G3, G4, or quicksilver cases and I've worked on a lot of them.
Now, I can rant on and on about iMac cases - it takes at least a half hour to remove a disk in any revision of the iMac. If your hand slips while putting it back together, you get a loose screw in the innards and you have to do the medicine-ball-dance to get it out.
If the envelope recipient is foo@example.com, then the delivering MTA will look up an MX record for example.com. Whether it resolves to a.mx.example.com or mx1.cheepmailhosting.com is irrelevant.
Incorrect; I looked up the RFCs and MX records cannot point to CNAME pointers according to rfc 974 (the reasoning is that it prevents a certain type of mail loop).
In addition, the process does not work as you described: if the message is addressed to @a.example.com and a.example.com is a CNAME alias, the MTA will look up the A RR that the CNAME points to and then look up the MX record for the A RR; it will not look up the MX record for the CNAME alias. This is also the step at which the address will be expanded from the CNAME to an A RR and this expansion does not just happen in the envelope, but the To, CC, etc. headers are modified.
So you cannot have CNAME RRs returned in MX records and it makes no sense to have an MX record for a CNAME alias since it won't be used. But this is irrelevant anyway since the address is not modified to contain the MX; the address is modified to contain the A RR and this is what users will see. If you simply want to receive mail @example.com, you could make example.com a CNAME alias; however, if you don't want addresses automatically exanded from "foo@example.com" to "foo@provider.com", "example.com" must have an A RR.
Example: find a random hosted page that only has a CNAME, not an A RR. For example, sourceforge has a CNAME wildcard record, so use "asdfasdf.sourceforge.net". Send mail to yourself, chaning the From address to "webmaster@asdfasdf.sourceforge.net"; make sure this mail goes through an MTA and is not just delivered locally. In the received message, note that the From header has been changed and you now have a mail "From: webmaster@projects.sourceforge.net" and not "From: webmaster@asdfasdf.sourceforge.net". This means that if you host two customers, say example1.com and example2.com and both want to receive mail at "webmaster@example1.com" and "webmaster@example2.com", one of them will need an A RR.
One thing that I have not seen many people mention in this discussion is the server-side analogue: Name-based virtual hosting.
Name-based virtual hosting works great for HTTP, but not so well for SMTP. Since the standards require a fully-qualified A-record in an email address, lots of MUAs will expand a CNAME pointer into an A-record; if the client doesn't do it, you can be sure some intervening MTA will. This makes sense since it's really the MX record that determines where the mail should go and MX records can only be associated with A records (AFAIK, don't remember from the DNS specs).
This basically means that if a customer wants user@example.com, domain.com has to have an A record. One could of course receive mail with only a CNAME, but since MUAs and MTAs automatically expand addresses to the A-record, the customer's correspondents will end up seeing "user@mx.provider.com" instead of "user@example.com". This is unsightly and causes confusion among non-tech types.
Since HTTP, SMTP and DNS are the primary services where people pay for hosting, it could be that SMTP creates a bottleneck in the IPv4 space.
The only thorn in the side of name-based vhosting is SSL.
This may be one of the reasons why START_TLS is preferred over SSL for new protocols. If HTTP used START_TLS instead of SSL, the client could transmit the Host header before the server needed to present a certificate.
OTOH, HTTP works very well right now, so I'm not suggesting messing with the spec to include START_TLS.
...was to be able to cut and paste between applications
Whenever X11 is discussed, someone brings this up and I give the same reply.
Copy and paste works in X11. It works the same way as MacOS or Windows. You can select text, copy it via a menu item or a keyboard shortcut, select over more text in a different application, and paste in the original text with a menu item or keyboard shortcut. That's it. Pretend there is no middle mouse button and everything will work like you expect.
Now, you're going to run into certain problems with certain ancient applications and toolkits that do not implement this correctly. Most notably, QT 2.x did this wrong and xterm does not allow you to "copy" as you expect (there is no copy menu item or shortcut). I think GNU Emacs also does this wrong. These applications and toolkits are actually fairly rare, but xterm and emacs are pretty popular programs.
Details: X11 keeps track of a clipboard and a selection. The selection is generally inserted whenever you middle-click. Middle-clicking does not paste from the clipboard - you have to use a menu item or keyboard shortcut to paste from the clipboard. Like I said, pretend there is no such thing as middle-click and cut and paste will work as in MacOS and Windows as long as you don't use xterm (instead use gterm or kterm or whatever the KDE/GNOME equivalents are called). Whoever told you that middle-clicking pastes misinformed you; no XFree86 documentation tells you this.
Please don't tell us we need a "unified API" for cut and paste. We have one, it works and all new applications use it. If you want to go and fix xterm, go for it, that's some real nice code for you to play with:) If you want to fix GNU Emacs, go suggest this on the emacs mailing lists and see how far you get:)
To stem any confusion: Barney is the name of the Bush dog. This may be widely known, but I don't keep up with the media and I thought you were talking about the purple dinosaur.
Most people suggest that they use apples, as they're what they already have laying around
Not necessarily. Apple computers are the only machines distinctive enough to benefit from product placement. If you put a Dell laptop in a film, how are people going to tell at a distance that it's a Dell and not a Toshiba or Compaq? Whenever you can recognize a product in a film, it's often a paid advertisement.
As for OSes, I think the film makers just want to make an impression, so they show something glitzy and unfamiliar. They don't want people distracted by the OS, thinking "hey that looks like my machine at home" or "what a loser, he's still using MSIE 4.x" instead of thinking about the plot and perhaps thinking "that guy is so 'leet, he doesn't even use Windows/MacOS." These could very well be flash programs.
Does anyone own a Zaurus? How useful are they really?
I have an SL-5500 and I don't find it too useful as-is.
All the stylus-based input methods suck. The region-based letter recognizer is unusable compared to Graffiti. It will also go to the Unicode input table when you hit some key combination, which is very annoying as you can't do anything with that and you have to reset it back to another input method. The upside is that you can write your own input system. I downloaded a version of QwikScript for the Zaurus, but it's more proof-of-concept code and is unusable without some recentering features, like the real QwikScript for PalmOS. If you want to input anything, you have to pull out the keyboard, which is annoying for quick notes. They keyboard is excellent, however.
Applications are often difficult to use. Most applications come with a workstation-like interface, with a title bar, a menu bar and an icon toolbar, which is not a very good idea when screen space is scarce. The good thing is that I've mapped the calendar button to tab, which means I can navigate the menus and most other elements using only the main buttons; sometimes I don't flip up the cover (SL-5500 has a clear cover) or pull down the keyboard to do something.
About the only thing you must use the stylus for switching applications.
There are other things wrong with the interface: for instance, most "themes" have various decorations for the scrollbar, which are not active (like Microsoft Windows, the rightmost two or three pixels are a border). When screen space is this scarce, this shouldn't happen. There's also dead space in the menus, the task bar and toolbars.
Lots of applications sometimes get too large for the screen (for instance, when you pop up an input method), which pops up a horizontal scrollbar for scrolling left or right only a few pixels. This leaves almost no room for the application window, so these applications are unusable.
There are plenty of examples of poor design or incorrect behaviour that you'll find yourself working around if you use a Zaurus. You don't find yourself doing this nearly as much with PalmOS.
The thing I use a PDA for the most is keeping track of Todo lists. I usually have from 500 to 1000 Todo items and these are unmanageable with the Zaurus Todo program. The searching, sorting and organizing features suck, so I'm stuck scrolling through all the items and the program is unbearably slow with so many items. Whenever you mark an item finished, it scrolls back to the top of the list and you can't see if you've marked the correct item since there's no visual feedback when you tap the checkbox (so you have to scroll back to where the item was (if you remember its context), which takes a very long time). My previous PDA was a Palm III, and it handled this volume of todos quite well.
Basically, I don't use my Zaurus because the software it comes with sucks. I've been meaning to write an alternative Todo list and add recentering to the QwikScript for Zaurus, but I haven't had the time.
This, however, brings me to the advantages of the Zaurus, the first of which is that lots of software for it (like OPIE) is open source. This means I could easily fix a lot of things if I had the time or motivation, whereas I'll never be able to to fix any bugs in WinCE or PalmOS.
The second advantage is that the APIs for programming the Zaurus are excellent. It has a version of Qt for the interface stuff, and you can use standard Linux/glibc for more low-level stuff. I wrote one application for the Zaurus for internal use and it was very easy, whereas it would have been a real pain in PalmOS or WinCE. Also, you can telnet into the zaurus when it's docked, there's a very good VNC server for the Zaurus and you can install gcc. Put together, this means you can control your Zaurus from the
PC it's docked to and do all your development on the Zaurus, but using the PC's keyboard and mouse.
Assuming one wishes to use a certificate signing authority, is there any downside to using Thawte at 1/8th the cost of Verisign?
I would recommend
www.freessl.com's ChainedSSL offering. It looks like it's now $50 for that product, whereas it used to be $35. However, they're now offering their "FreeSSL" product for $35 (it used to cost more). Both are functionally equivalent: one is directly signed by a root CA, whereas one is signed by a CA which is signed by a root CA (all web browsers I've seen deal with this just fine).
The CA might not be recognized in some older less-common browsers (such as older builds of Mozilla), but it's recognized by the major browsers (MSIE, branded Netscape, Opera, etc.). Not a big deal since people running more esoteric browsers are probably technical types who won't be terrified at the prospect of importing a certificate.
The verification process is phone-based, like other vendors. The certificates come in a number of formats. Don't know anything about their tech support, but I can't imagine any situation in which tech support would be needed since you're buying some bytes, a one-shot deal.
They also offer a wildcard certificate (*.your.domain.com) for $200.
If you're not a hosting ISP, I would also recommend limiting the number of public sites that run SSL and setting up your own CA for internal sites where you can more easily distribute your own certificates. The whole SSL signing thing is just a big racket, since the signing procedures don't really verify identity. I think all they do for verification is check that your area code and your ZIP code match up (perhaps using some fancy telecom trick instead of caller ID).
What do you mean? I'm ssh'd into my iPaq right now.
Right, but your iPaq isn't running the OS it came with:)
No big deal for a personal device, but I needed to get my app out "into the field" PDQ - no time to tweak kernel cross-compile options, boot off CF or figure out what's changed with hardware revisions.
Hell, during the last 12 months, I've probably written at least 60% of all the code I've written (and tested) all on a PDA
Excuse the term, but that's fucking crazy. You know that you can telnet into a zaurus? And you know there's a very good VNC server package so you can test GUI stuff with a real mouse?
I've written some code for the Zaurus (custom database-type app). I ended up actually writing and testing a good portion of the code on the device itself, but I would have gotten nowhere flat without telnet (+gcc +vi) and VNC. In fact, this was one of the two big reasons we went with the Zaurus for this app instead of Pocket PC, since that's not really possible with Pocket PC and it's a PITA to write code on the PC and see it break on the PDA due to some poorly documented API. The other big reason was QT Embedded instead of Platform SDK.
I gather that you are not greatly experienced in programming and system administration?
Incorrect. If you wish, I'll write these programs (windows service, low LOC, no exploits, similar functionality) and post them to my journal, like I've posted before when challenged (lameness filter prevents posting code as comments). I find it difficult to believe that you doubt such a thing can be done trivially. Indeed the messenger service has such little functionality that it's embarassing it could be exploited.
Not being a Windows expert, what does Windows Messenger really do in a system?
It does not do anything important. The messenger service accepts text messages over the network (from anywhere) and displays them in a message box. You can test this using "net send" from the command line. I believe messenger was meant as a replacement for "winpopup" from win9x.
I've heard of three uses for this service:
(1) some administrators apparently use this to send some notifications to their users about network outages or whatever. I have no sympathy for these administrators since it's absolutely trivial to write a replacement. Shouldn't be more than thirty lines of code for both client and server that use unadorned TCP and you can be damn sure that thirty lines of code you write won't contain an idiotic buffer overflow and you can also implement access controls to ensure your replacement won't be abused by other employees (whereas messenger accepts messages from anywhere and does not inform you of their origin).
(2) I've heard that certain printers or printing systems use this to notify users of conditions like low toner. Again, I have no sympathy since this should be done with SNMP traps. With SNMP traps, you can re-route these messages or write some program to deal with them automatically (page your "paper/toner" guy when toner is low, or automatically file a paper request with the supplies people). You cannot do this with undocument proprietary Microsoft protocols like messenger (although messenger is probably simple enough that you could easily reverse-engineer it (like the people in group (3) did), but there is no reverse engineering involved with standard protocols like SNMP).
(3) Messenger is used by spammers to display spam on your desktop. Since it accepts messages from anywhere and does not log the origininating IP of the messages, it's quite convenient for this purpose.
It is completely safe and very recommended to disable messenger. It is enabled by default in all recent versions of Windows.
I don't think any of the free *nixes are better or worse as desktop systems. They can all compile the same Mozilla, mplayer or whatever and since I'm the type that always tweaks compile-time options instead of using pre-compiled packages, all the *nixes are the same to me desktop-wise.
The only real difference is that I don't need to fiddle with alternative ABIs or wrapper scripts to run vmware on Linux or Opera on FreeBSD but that's not that big a deal since any OS can give me a terminal and a decent browser.
I use FreeBSD at home so I can keep up with -CURRENT whereas I stay with -STABLE on the boxes at work. If my nat box at home breaks due to a cvsup, I can just plug a laptop into the dsl modem to deal with some emergency call. Since I hear only good things about pf, I might return to OpenBSD at home since it really can't hurt anything. The only reason I wouldn't use it at work is because I've set up a mostly FreeBSD shop and I don't want my future replacement to find himself with fifteen different OSes to admin.
FreeBSD already has two firewall systems: ipf (old and crufty (but cross-platform (Solaris) which is kind of useful)) and ipfw (which seems to get the major work, with ipfw2 having some neat tricks). If they add pf, they'll have three (four if you count ipfw1 and ipfw2 in the 4- series, but you have to choose between one of these two, whereas you can run ipf alongside ipfw). And then it also has IPSEC, which can do some firewally stuff with DENY policies. And then it also has divert sockets, which allow you to write your own userspace firewall systems (among other things).
The 3.1 song was the best. This one is weird - but nice lyrics.
Lots of changes in the release: looks like a large code audit, ProPolice in the kernel, libraries loaded at random addresses, W^X for i386. Looks good. Haven't used with OpenBSD since 2.8 (went to FreeBSD), but this I might try this one.
I only do mail for one small group of (non-technical) people and I don't do anything spam-wise for them (other than the base+suffix trick) since they haven't asked and I don't have time. The most I would do if asked is to install spamassassin or similar or go with a very conservative blacklist. I've seen njabl used and it catches a lot of spam without raising a lot of legitimate complaints. They classify hosts, so you can, for instance, block open relays and open proxies but allow through dynamically-assigned dialup IPs if needed. However, I wouldn't do any tricks like requiring valid originating MXes or even doing reverse DNS lookups on incoming IPs since I don't want to deal with the support issues.
I don't know how to make spam go away for good. I'm also not motivated to do a lot of thinking or experimentation on the problem since the base+suffix trick eliminated all my spam.
By the way, the papers are pretty interesting.
This gives me:
Igor could not debug your program. While debugging, Igor encountered an internal error during execution.
The AskIgor maintainers have been notified. This is an urgent problem which will be fixed soon. Any new diagnosis will be shown on this page.
50 000 000 / 2 = 25 000 000
25 000 000 * 5 = 125 000 000
That's $125 million, not $1.25 billion.
Consider this: I need to send work-related mail from home. My ISP, in an effort to stop spam, only allows their outgoing mail server to handle mail where FROM is one of their addresses. I can no longer send work-related mail from home to you.
Now I'm not particularly interested in "workarounds" since this is not a problem for me personally (I avoid graphical mail clients). Consider that it's a real problem for a large number of people whose companies don't have VPNs and who do not have the skill or motivation to set up ssh tunelling or some other kind of tunnel. It's also an inconvenience for people like me that have multiple addresses in multiple domains who would have to hack their MUA to recognize (based on from address) which outgoing mail server to use (and how to set up a tunnel to that server if necessary).
If you're doing this to deal with your own personal mail, then go for it. However, you may want to reconsider before implementing this for some company or group of people.
To demonstrate: on any of your clients, type "niutil -readprop -t server_ip/network /users/username/passwd"
Substitute "username" with any username or read all the usernames. Hell, I'll script it for you:
The hashes are encrypted using the standard Unix crypt(3). You can then massage them into some format that Crack can read and let it go. Remember, any user with access to your network can do this.
I really thought it was quite irresponsible of Apple to release this software and recommend this configuration to users. It took them a good long time to fix it.
Panther (client) finally fixed this. You'll note that passwords are no longer stored in netinfo, but netinfo rather references a "guid" which in turn references a file that stores the password, readable only by root. This means that standalone Macs no longer give all users access to all password hashes. I understand netinfo will finally be fully deprecated in 10.3 server.
You also asked if anyone has had other problems with MacOS X Server: I would strongly recommend against their mail server software. It does finally store messages as discrete files on the filesystem, so some munging can be fixed, but message flags are still stored in some opaque binary format that tends to get corrupted. In fact, whenever 10.2 server goes down ungracefully, all flags on messages are corrupted on our mail server, and thousands of deleted (and purged) messages re-appear in all the inboxes. The particular machine is on a UPS, so this doesn't happen very often, but it happens whenever the machine is purposefully rebooted without first explicitly stopping the mail server.
The good thing about 10.2 server is that it stores the passwords using standard DES crypt(), which makes migrating from it very easy. A shell script like the one above can produce a password file readable by most any *nix flavor. 10.3 uses some bizaare format that I can't readily identify. Since a lot of the most important bits of MacOS are closed-source, you may have a very difficult time migrating away from 10.3 server if it uses something akin to the 10.3 client hashes (options are making all users create new passwords or spending lots of time reverse-engineering the hash and writing an equivalent pam module for another OS (I'm assumming this new hashing stuff is not in Darwin, as most things in MacOS where I needed the code were not in Darwin - but I haven't checked for this)).
Anyway, your best bet is to drop netinfo and start using LDAP. MacOS X (client and server) uses OpenLDAP, which doesn't have these security issues, is easy to migrate onto other OSes, and is open source (with no modifications that I can identify), so you at least have the ability to fix your own problems if you're not scared of some coding. For example, the OpenLDAP version that ships with MacOS X 10.2 has a bug in that TLS_CACERTDIR directive does not work. I was able to identify and work around this since I had access to the code.
In Finder, Go -> Connect to Server, type in ftp://some.site.tld/path
Read-only, which is probably a good thing since password is sent clear-text.
The hard disk bracket is connected with one very small low-profile philips screw in an awkwardly-placed recessed counter-sunk hole. I've stripped a number of these screws. I've taken to moving the hard disk from the bottom position in the bracket to the top position so the screw could be replaced with a standard screw with a deeper head.
Past that, I have no complaints about the b/w G3, G4, or quicksilver cases and I've worked on a lot of them.
Now, I can rant on and on about iMac cases - it takes at least a half hour to remove a disk in any revision of the iMac. If your hand slips while putting it back together, you get a loose screw in the innards and you have to do the medicine-ball-dance to get it out.
Likely that IRIX still uses getpass(3) in some places with the max length defined to 8. Solaris 8 does this too (don't know about Solaris 9).
Incorrect; I looked up the RFCs and MX records cannot point to CNAME pointers according to rfc 974 (the reasoning is that it prevents a certain type of mail loop).
In addition, the process does not work as you described: if the message is addressed to @a.example.com and a.example.com is a CNAME alias, the MTA will look up the A RR that the CNAME points to and then look up the MX record for the A RR; it will not look up the MX record for the CNAME alias. This is also the step at which the address will be expanded from the CNAME to an A RR and this expansion does not just happen in the envelope, but the To, CC, etc. headers are modified.
So you cannot have CNAME RRs returned in MX records and it makes no sense to have an MX record for a CNAME alias since it won't be used. But this is irrelevant anyway since the address is not modified to contain the MX; the address is modified to contain the A RR and this is what users will see. If you simply want to receive mail @example.com, you could make example.com a CNAME alias; however, if you don't want addresses automatically exanded from "foo@example.com" to "foo@provider.com", "example.com" must have an A RR.
Example: find a random hosted page that only has a CNAME, not an A RR. For example, sourceforge has a CNAME wildcard record, so use "asdfasdf.sourceforge.net". Send mail to yourself, chaning the From address to "webmaster@asdfasdf.sourceforge.net"; make sure this mail goes through an MTA and is not just delivered locally. In the received message, note that the From header has been changed and you now have a mail "From: webmaster@projects.sourceforge.net" and not "From: webmaster@asdfasdf.sourceforge.net". This means that if you host two customers, say example1.com and example2.com and both want to receive mail at "webmaster@example1.com" and "webmaster@example2.com", one of them will need an A RR.
Name-based virtual hosting works great for HTTP, but not so well for SMTP. Since the standards require a fully-qualified A-record in an email address, lots of MUAs will expand a CNAME pointer into an A-record; if the client doesn't do it, you can be sure some intervening MTA will. This makes sense since it's really the MX record that determines where the mail should go and MX records can only be associated with A records (AFAIK, don't remember from the DNS specs).
This basically means that if a customer wants user@example.com, domain.com has to have an A record. One could of course receive mail with only a CNAME, but since MUAs and MTAs automatically expand addresses to the A-record, the customer's correspondents will end up seeing "user@mx.provider.com" instead of "user@example.com". This is unsightly and causes confusion among non-tech types. Since HTTP, SMTP and DNS are the primary services where people pay for hosting, it could be that SMTP creates a bottleneck in the IPv4 space.
The only thorn in the side of name-based vhosting is SSL.
This may be one of the reasons why START_TLS is preferred over SSL for new protocols. If HTTP used START_TLS instead of SSL, the client could transmit the Host header before the server needed to present a certificate.
OTOH, HTTP works very well right now, so I'm not suggesting messing with the spec to include START_TLS.
Whenever X11 is discussed, someone brings this up and I give the same reply.
Copy and paste works in X11. It works the same way as MacOS or Windows. You can select text, copy it via a menu item or a keyboard shortcut, select over more text in a different application, and paste in the original text with a menu item or keyboard shortcut. That's it. Pretend there is no middle mouse button and everything will work like you expect.
Now, you're going to run into certain problems with certain ancient applications and toolkits that do not implement this correctly. Most notably, QT 2.x did this wrong and xterm does not allow you to "copy" as you expect (there is no copy menu item or shortcut). I think GNU Emacs also does this wrong. These applications and toolkits are actually fairly rare, but xterm and emacs are pretty popular programs.
Details: X11 keeps track of a clipboard and a selection. The selection is generally inserted whenever you middle-click. Middle-clicking does not paste from the clipboard - you have to use a menu item or keyboard shortcut to paste from the clipboard. Like I said, pretend there is no such thing as middle-click and cut and paste will work as in MacOS and Windows as long as you don't use xterm (instead use gterm or kterm or whatever the KDE/GNOME equivalents are called). Whoever told you that middle-clicking pastes misinformed you; no XFree86 documentation tells you this.
Please don't tell us we need a "unified API" for cut and paste. We have one, it works and all new applications use it. If you want to go and fix xterm, go for it, that's some real nice code for you to play with :) If you want to fix GNU Emacs, go suggest this on the emacs mailing lists and see how far you get :)
To stem any confusion: Barney is the name of the Bush dog. This may be widely known, but I don't keep up with the media and I thought you were talking about the purple dinosaur.
Not necessarily. Apple computers are the only machines distinctive enough to benefit from product placement. If you put a Dell laptop in a film, how are people going to tell at a distance that it's a Dell and not a Toshiba or Compaq? Whenever you can recognize a product in a film, it's often a paid advertisement.
As for OSes, I think the film makers just want to make an impression, so they show something glitzy and unfamiliar. They don't want people distracted by the OS, thinking "hey that looks like my machine at home" or "what a loser, he's still using MSIE 4.x" instead of thinking about the plot and perhaps thinking "that guy is so 'leet, he doesn't even use Windows/MacOS." These could very well be flash programs.
What software do you use to read ebooks? I tried using the kpdf port, but it would take several minutes to load a page with a large file.
I have an SL-5500 and I don't find it too useful as-is.
All the stylus-based input methods suck. The region-based letter recognizer is unusable compared to Graffiti. It will also go to the Unicode input table when you hit some key combination, which is very annoying as you can't do anything with that and you have to reset it back to another input method. The upside is that you can write your own input system. I downloaded a version of QwikScript for the Zaurus, but it's more proof-of-concept code and is unusable without some recentering features, like the real QwikScript for PalmOS. If you want to input anything, you have to pull out the keyboard, which is annoying for quick notes. They keyboard is excellent, however.
Applications are often difficult to use. Most applications come with a workstation-like interface, with a title bar, a menu bar and an icon toolbar, which is not a very good idea when screen space is scarce. The good thing is that I've mapped the calendar button to tab, which means I can navigate the menus and most other elements using only the main buttons; sometimes I don't flip up the cover (SL-5500 has a clear cover) or pull down the keyboard to do something. About the only thing you must use the stylus for switching applications.
There are other things wrong with the interface: for instance, most "themes" have various decorations for the scrollbar, which are not active (like Microsoft Windows, the rightmost two or three pixels are a border). When screen space is this scarce, this shouldn't happen. There's also dead space in the menus, the task bar and toolbars.
Lots of applications sometimes get too large for the screen (for instance, when you pop up an input method), which pops up a horizontal scrollbar for scrolling left or right only a few pixels. This leaves almost no room for the application window, so these applications are unusable.
There are plenty of examples of poor design or incorrect behaviour that you'll find yourself working around if you use a Zaurus. You don't find yourself doing this nearly as much with PalmOS.
The thing I use a PDA for the most is keeping track of Todo lists. I usually have from 500 to 1000 Todo items and these are unmanageable with the Zaurus Todo program. The searching, sorting and organizing features suck, so I'm stuck scrolling through all the items and the program is unbearably slow with so many items. Whenever you mark an item finished, it scrolls back to the top of the list and you can't see if you've marked the correct item since there's no visual feedback when you tap the checkbox (so you have to scroll back to where the item was (if you remember its context), which takes a very long time). My previous PDA was a Palm III, and it handled this volume of todos quite well.
Basically, I don't use my Zaurus because the software it comes with sucks. I've been meaning to write an alternative Todo list and add recentering to the QwikScript for Zaurus, but I haven't had the time.
This, however, brings me to the advantages of the Zaurus, the first of which is that lots of software for it (like OPIE) is open source. This means I could easily fix a lot of things if I had the time or motivation, whereas I'll never be able to to fix any bugs in WinCE or PalmOS.
The second advantage is that the APIs for programming the Zaurus are excellent. It has a version of Qt for the interface stuff, and you can use standard Linux/glibc for more low-level stuff. I wrote one application for the Zaurus for internal use and it was very easy, whereas it would have been a real pain in PalmOS or WinCE. Also, you can telnet into the zaurus when it's docked, there's a very good VNC server for the Zaurus and you can install gcc. Put together, this means you can control your Zaurus from the PC it's docked to and do all your development on the Zaurus, but using the PC's keyboard and mouse.
The third advantage i
I would recommend www.freessl.com's ChainedSSL offering. It looks like it's now $50 for that product, whereas it used to be $35. However, they're now offering their "FreeSSL" product for $35 (it used to cost more). Both are functionally equivalent: one is directly signed by a root CA, whereas one is signed by a CA which is signed by a root CA (all web browsers I've seen deal with this just fine).
The CA might not be recognized in some older less-common browsers (such as older builds of Mozilla), but it's recognized by the major browsers (MSIE, branded Netscape, Opera, etc.). Not a big deal since people running more esoteric browsers are probably technical types who won't be terrified at the prospect of importing a certificate.
The verification process is phone-based, like other vendors. The certificates come in a number of formats. Don't know anything about their tech support, but I can't imagine any situation in which tech support would be needed since you're buying some bytes, a one-shot deal. They also offer a wildcard certificate (*.your.domain.com) for $200.
If you're not a hosting ISP, I would also recommend limiting the number of public sites that run SSL and setting up your own CA for internal sites where you can more easily distribute your own certificates. The whole SSL signing thing is just a big racket, since the signing procedures don't really verify identity. I think all they do for verification is check that your area code and your ZIP code match up (perhaps using some fancy telecom trick instead of caller ID).
Right, but your iPaq isn't running the OS it came with :)
No big deal for a personal device, but I needed to get my app out "into the field" PDQ - no time to tweak kernel cross-compile options, boot off CF or figure out what's changed with hardware revisions.
standard way:
Excuse the term, but that's fucking crazy. You know that you can telnet into a zaurus? And you know there's a very good VNC server package so you can test GUI stuff with a real mouse?
I've written some code for the Zaurus (custom database-type app). I ended up actually writing and testing a good portion of the code on the device itself, but I would have gotten nowhere flat without telnet (+gcc +vi) and VNC. In fact, this was one of the two big reasons we went with the Zaurus for this app instead of Pocket PC, since that's not really possible with Pocket PC and it's a PITA to write code on the PC and see it break on the PDA due to some poorly documented API. The other big reason was QT Embedded instead of Platform SDK.
Incorrect. If you wish, I'll write these programs (windows service, low LOC, no exploits, similar functionality) and post them to my journal, like I've posted before when challenged (lameness filter prevents posting code as comments). I find it difficult to believe that you doubt such a thing can be done trivially. Indeed the messenger service has such little functionality that it's embarassing it could be exploited.
It does not do anything important. The messenger service accepts text messages over the network (from anywhere) and displays them in a message box. You can test this using "net send" from the command line. I believe messenger was meant as a replacement for "winpopup" from win9x.
I've heard of three uses for this service:
(1) some administrators apparently use this to send some notifications to their users about network outages or whatever. I have no sympathy for these administrators since it's absolutely trivial to write a replacement. Shouldn't be more than thirty lines of code for both client and server that use unadorned TCP and you can be damn sure that thirty lines of code you write won't contain an idiotic buffer overflow and you can also implement access controls to ensure your replacement won't be abused by other employees (whereas messenger accepts messages from anywhere and does not inform you of their origin).
(2) I've heard that certain printers or printing systems use this to notify users of conditions like low toner. Again, I have no sympathy since this should be done with SNMP traps. With SNMP traps, you can re-route these messages or write some program to deal with them automatically (page your "paper/toner" guy when toner is low, or automatically file a paper request with the supplies people). You cannot do this with undocument proprietary Microsoft protocols like messenger (although messenger is probably simple enough that you could easily reverse-engineer it (like the people in group (3) did), but there is no reverse engineering involved with standard protocols like SNMP).
(3) Messenger is used by spammers to display spam on your desktop. Since it accepts messages from anywhere and does not log the origininating IP of the messages, it's quite convenient for this purpose.
It is completely safe and very recommended to disable messenger. It is enabled by default in all recent versions of Windows.
I use FreeBSD at home so I can keep up with -CURRENT whereas I stay with -STABLE on the boxes at work. If my nat box at home breaks due to a cvsup, I can just plug a laptop into the dsl modem to deal with some emergency call. Since I hear only good things about pf, I might return to OpenBSD at home since it really can't hurt anything. The only reason I wouldn't use it at work is because I've set up a mostly FreeBSD shop and I don't want my future replacement to find himself with fifteen different OSes to admin.
That's kind of crazy.
The 3.1 song was the best. This one is weird - but nice lyrics.
Lots of changes in the release: looks like a large code audit, ProPolice in the kernel, libraries loaded at random addresses, W^X for i386. Looks good. Haven't used with OpenBSD since 2.8 (went to FreeBSD), but this I might try this one.