Probably going to bring us a whole new dimension in online marketing, God forbid.
Actually, designers of anything IPM-like in the recent 5 years are well aware of the spam problem. Jabber, by default, won't accept messages from anyone/anything beyond your roster. The only threat I can think of is that servers start sneak text ads inside vital message fields (any extensions can be easily ignored). But then, you can always change a server or roll your own, because the Jabber network is totally open.
Please, everyone, don't tell CNN about Jabber. If the journos learn that it's a new haven for "HACKERS", where they *gasp* can use encryption, our asses will burn.
*Sigh* when will everybody learn that all these messages are from yahoo in the same way as I'm a Korean schoolgirl operating an open relay. The sender's address is forged as easy as a piss. You have to poke around "Received:" headers to determine the real origin of a message.
This scheme is common for Europe, too. I believe, this is because ISPs themselves pay per gigabyte for the overseas traffic, and this share of traffic is much larger than what ISPs have in the US (the Net is still US-centric, remember?). Here in Moscow, they start ripping me off after 300 Mb *groan*
Procmail's "language" is actually pretty logical, once you get past weird markers like "0:" and "*". My main trouble with procmail is that it doesn't compile its rules into some binary representation for easy loading (since there is no daemon, which, OTOH, would rather be an overkill for most filtering needs). Is there some open-source mail filter that doesn't reparse its rules on each run?
* Even doing something that should be simple like changing your timezone is done with an overcomplicated application with no help of any kind (You see a screen with a world map, and you have to *guess* where your city is located by tapping on the worldmap to set the timezone correctly).
Erm... You cannot point where your city is located on a world map? Not even approximately? Oh, let me guess: you know IP zones better than you do geography, right? Don't know either? I pity you.
Pocket PC is awful to develop applications to; it feels like MS treats independent developers like unwanted scum. With each new version, important APIs are being swapped behind your feet (don't EVER try to use system email APIs in WinCE, lest you be sorry); the documentation delicately avoids some tricky details and describes things that won't work; known bugs are let exist for years. Hey, you don't pay for support, how could you deserve decent documentation?
Compared to this, Zaurus is a campers' paradise. I hope the mindshare among developers will prove me right in coming years. The Microsoft development culture, comprised of paranoidal information concealment and schizophrenical self-inconsistence, should be turned down.
And I wonder how long until spammers start databasing whitelisted recipients
Since whitelists are built per recipient, such a database would require keeping pairs: (sender address, recipient address) This is impossible to build automatically without tracking the recipient's incoming mail. A tactic to guess whitelisted recipients would be to spoof known addresses from the same or related domains, assuming that addresses from the same entity have greater chance to be whitelisted. But this would require Much Of Effort (the key point of TMDA). And such spam tactics will be the reason for people to start using PGP massively. Hmm, someone should definitely try this!:-)
A slightly easier spoil tactic is to develop auto-confirmation. But, as the TMDA white papers notice, this 1) requires to disclose a working email address, easy to blacklist; 2) imposes technical costs unseen by the spammers of today: sending 100000 unique confirmations is not the same as banging an open relay with 500 messages each having 200 recipients.
Forging the "From:" header is the first thing any aspiring spammer learns. You can trust only "Received:", one of them, which has been bumped by your ISP's mail server.
What's far more annoying, in my opinion, is those sites who've configured their mail server to be utterly anal about DNS. Forward mapping, reverse mapping, no underscores, etc. etc.
Underscores? Quit smoking crack and read the RFCs.
Reverse mapping is a good thing for legitimate mail servers to have. Don't let slimy "direct marketers" make you believe otherwise.
Because performance and scalability is always the first and last issue in any argument.
That's because we, the practicing programmers, live and die by it.
The fact that the Java X server is portable to any system that has Java is irrelevant.
Sorry to burst your bubble, but this server has to interact with different low-level interfaces to graphical hardware in order to be portable. Unless Java has become able to do ioctl's and map physical memory, it can't be done without JNI magic. Of course, you can run X server inside an AWT window, but this makes your entire point laughable.
whether it can create a window for Mozilla in 2.4 microseconds (which Mozilla will take 12.7 seconds to draw in) is.
What's relevant is whether it doesn't take forever to open an xterm.
A Fortran implemenation will be faster, though, as will an assembly implemenation. All hail Fortran and assmebly.
This is all flames. Use the tool that fits the job, not some high-horse languages because they rock your world (and they rock mine, too; I just wouldn't bet my life on them).
There's no reason why it couldn't be done in Lisp or Java, and I believe there's been at least one implementation in each. See http://www.jcraft.com/weirdx/ for the Java implementation.
For the discourse at hand, it'd be nice to consider performance/scalability figures.
Both Lisp machines and VMS are examples of systems that don't depend on C.
Have you ever gotten used to working in a Unix/Linux shell then had to jump over to Windows and do something on the command line in *DOS*? Know what that feels like, that helpless feeling of losing all your magical powers?
Um... Isn't that because you do lose all your magical powers?
They have a really good shot at doing so given Java's performance problems [insert thousands of flames from Java developers here]
OK, here's mine: Had anyone heard anything about real CLR performance? Major JVM implementations have shitloads of work poured into them in the recent 7 years, and still they can't come anywhere close to the native code performance-wise. Do you believe Microsoft somehow made it at the before-release chest-drumming stage?
Slashdot Mirror
Probably going to bring us a whole new dimension in online marketing, God forbid.
Actually, designers of anything IPM-like in the recent 5 years are well aware of the spam problem. Jabber, by default, won't accept messages from anyone/anything beyond your roster. The only
threat I can think of is that servers start sneak text ads inside vital message fields (any extensions can be easily ignored). But then, you can always change a server or roll your own, because the Jabber network is totally open.
Please, everyone, don't tell CNN about Jabber.
If the journos learn that it's a new haven for "HACKERS", where they *gasp* can use encryption, our asses will burn.
*Sigh* when will everybody learn that all these messages are from yahoo in the same way as I'm a Korean schoolgirl operating an open relay.
The sender's address is forged as easy as a piss.
You have to poke around "Received:" headers to determine the real origin of a message.
This scheme is common for Europe, too. I believe, this is because ISPs themselves pay per gigabyte for the overseas traffic, and this share of traffic is much larger than what ISPs have in the US (the Net is still US-centric, remember?). Here in Moscow, they start ripping me off after 300 Mb *groan*
Procmail's "language" is actually pretty logical, once you get past weird markers like "0:" and "*".
My main trouble with procmail is that it doesn't compile its rules into some binary representation for easy loading (since there is no daemon, which, OTOH, would rather be an overkill for most filtering needs). Is there some open-source mail filter that doesn't reparse its rules on each run?
* Even doing something that should be simple like changing your timezone is done with an overcomplicated application with no help of any kind (You see a screen with a world map, and you have to *guess* where your city is located by tapping on the worldmap to set the timezone correctly).
Erm... You cannot point where your city is located on a world map? Not even approximately? Oh, let me guess: you know IP zones better than you do geography, right? Don't know either? I pity you.
Pocket PC is awful to develop applications to; it feels like MS treats independent developers like unwanted scum. With each new version, important APIs are being swapped behind your feet (don't EVER try to use system email APIs in WinCE, lest you be sorry); the documentation delicately avoids some tricky details and describes things that won't work; known bugs are let exist for years. Hey, you don't pay for support, how could you deserve decent documentation?
Compared to this, Zaurus is a campers' paradise. I hope the mindshare among developers will prove me right in coming years. The Microsoft development culture, comprised of paranoidal information concealment and schizophrenical self-inconsistence, should be turned down.
See Google Erasure of Anti-Scientology Links .
And I wonder how long until spammers start databasing whitelisted recipients
:-)
Since whitelists are built per recipient, such a database would require keeping pairs:
(sender address, recipient address)
This is impossible to build automatically without tracking the recipient's incoming mail.
A tactic to guess whitelisted recipients would be to spoof known addresses from the same or related domains, assuming that addresses from the same entity have greater chance to be whitelisted. But this would require Much Of Effort (the key point of TMDA). And such spam tactics will be the reason for people to start using PGP massively. Hmm, someone should definitely try this!
A slightly easier spoil tactic is to develop auto-confirmation. But, as the TMDA white papers notice, this 1) requires to disclose a working email address, easy to blacklist; 2) imposes technical costs unseen by the spammers of today: sending 100000 unique confirmations is not the same as banging an open relay with 500 messages each having 200 recipients.
Why reinvent communication libs when we have CORBA?
Not only is your target moving...It's picking up speed.
And lo, it's taking a U-turn and locking you in the crosshairs!
The aircraft behind is the thing's launch carrier, M-55X. Will Cosmopolis be the first successful airborne-launch space project?
Forging the "From:" header is the first thing any aspiring spammer learns. You can trust only "Received:", one of them, which has been bumped by your ISP's mail server.
OK, I need to pull some ropes at Rosaviakosmos. They send him up, then comes a sudden depressurisation when he is the One Kid In The Block. Oops...
It's just the exported name for "Chief FUD Officer".
May it be
when darkness falls
your phone will ring true
Underscores? Quit smoking crack and read the RFCs.
Reverse mapping is a good thing for legitimate mail servers to have. Don't let slimy "direct marketers" make you believe otherwise.
Is there more future generations can learn from the kind of spaghetti code that is commonly produced after OOP became the dominant paradigm?
Is that "some things never change"?
instead of being able to write unsafe code in java we're forced to use JNI and code in C.
A good price for not having to kludge the syntax, IMHO.
And code "In C".
Because performance and scalability is always the first and last issue in any argument.
That's because we, the practicing programmers, live and die by it.
The fact that the Java X server is portable to any system that has Java is irrelevant.
Sorry to burst your bubble, but this server has to interact with different low-level interfaces to graphical hardware in order to be portable. Unless Java has become able to do ioctl's and map physical memory, it can't be done without JNI magic. Of course, you can run X server inside an AWT window, but this makes your entire point laughable.
whether it can create a window for Mozilla in 2.4 microseconds (which Mozilla will take 12.7 seconds to draw in) is.
What's relevant is whether it doesn't take forever to open an xterm.
A Fortran implemenation will be faster, though, as will an assembly implemenation. All hail Fortran and assmebly.
This is all flames. Use the tool that fits the job, not some high-horse languages because they rock your world (and they rock mine, too; I just wouldn't bet my life on them).
For the discourse at hand, it'd be nice to consider performance/scalability figures.
Sorry, I don't see many of those around me.
Um... Isn't that because you do lose all your magical powers?
They have a really good shot at doing so given Java's performance problems [insert thousands of flames from Java developers here]
OK, here's mine: Had anyone heard anything about real CLR performance? Major JVM implementations have shitloads of work poured into them in the recent 7 years, and still they can't come anywhere close to the native code performance-wise. Do you believe Microsoft somehow made it at the before-release chest-drumming stage?
OK, go on and implement X in Lisp/Java/MSIL/whatever. Or maybe you prefer the GNU C library (which, if you didn't know, powers Lisp/Java/whatever)?