... Because you don't want a lossy graphic format. Of the popular web-able graphics (GIF, PNG, JPEG), JPEG doesn't retain the true graphic. Look at any graph that's been converted to JPEG by someone who doesn't know it gets its compression by bluring the sharp color changes. GIF and PNG get compression by removing duplicate strings of pixels, or by reducing the depth of colors available, rather than removing sharpness.
Try touching up a map after it's been converted to a JPEG. It's not going to look good. Been there, done that, now I sell the T-shirts!
Some time ago (years, in fact), I converted one of my sites to a "LZW-free zone". I did a lot of work in determining what browsers would work/not work with PNG.
What I found was that, while Internet Explorer has the most problem with PNG, PNGs can be displayed in all 5.x versions, provided they have HTML wrapped around them. That is, you can't always get the picture if you try to display http://a.b/this.png, it would work if you had http://a.b/this.htm, and this.htm was nothing more than an IMG tag containing http://a.b/this.png.
I took advantage of this to replace all the "display a GIF" links to add navigation buttons to the new page. (Turns out that Mozilla has this restriction, too)
Since then, I've done a lot of work with dynamically generated graphics, and it's been almost exclusively PNG. My biggest problem has been that IE and other browsers ignore the pixels/cm size parameter of PNG, and assume that all graphics are 72dpi, just like GIF. One of my most-used graphics is a 1200x1600 300dpi "label", which should be a half-page when printed. It's 4 times that size if you let the browser print it... Except when I wrap it in an IMG tag that says to scale it to 600x800!
Selects an SMTP server from the following hard-coded list:
The security advisory then lists a dozen or so popular multi-stage relays, from some major ISPs. This explains why my system was being hit by Verizon servers over a thousand times this weekend, targeting a non-existant address.
And here I thought it was just their normal "ignore the 550 response code, just retry endlessly" configuration! Turns out, it was just their "Relay anything for anyone" configuration!
What I want from programs like Quicken and Money is something to keep the check register. I don't want online banking (they can't steal from you electronically if you forbid online access to your account). I don't want stock portfolio management. And, most of all, I don't want [expletive deleted] advertisements popping up every day or two trying to sell me on these services... or suggesting that I update to the latest version, because it has improved support for things I don't do.
Frankly, I've switched to Money for one reason... it is possible to disable all advertising. I have not found an official way to do that in Intuit products, short of deleting the file that contains the ads... and that only kills 90% of them.
Inertia is all that stops me now from moving to a different (probably open-source) check register program. I've got Money 2000 tweaked the way I want it. But, if it decides to show me an ad again... BAM! To the moon! B-)
When chosing between two evils, I try to chose NEITHER.
Had the patch been automatically applied, it might be hours discovering WHY the system stopped working, then time spent figuring out whether or not the patch could be rolled back (remember, some MS patches are ONE WAY!), then rolling it back... Assuming it didn't corrupt your data along the way.
Autopatching is likely to become the wave of the future, but I hope Microsoft allows you to manually override it. Maybe they can make it pop up a modal dialog box to confirm that you're ready for them to corrupt^H^H^H^H^H^H^Hpatch your system...
A real patch, not just some KB article telling you to edit the registry.
The really unfortunate part of all this is that you can run a configuration like I do - treat all of internet as "restricted", disallow all scripting, don't trust any downloads - and not be vulnerable to something like this. My system's configuration requires that I tag windowsupdate.microsoft.com as a "trusted" site in order to get updates!
But it means that hundreds of common websites stop working. Microsoft decided to join the control of ALL scripting under a few settings. In order to stop the execution of untrusted Active-X controls, I end up disabling the execution of Adobe Acrobat, for example. And some versions of IE don't separate Javascript from Active-X when it comes from disabling scripting.
This isn't to say I'm really happy with how Mozilla does things. I would MUCH prefer it if I had the "trusted sites" concept in Mozilla/FireFox, because I could universally disable Javascript, yet have it come back on when I visit my own servers, or those vendor sites that need it. FireFox, at least, will allow quick access to the toggle-Javascript button, but Mozilla requires far too many mouse clicks to do it.
Opera has nice, fast access to scripting controls. If it didn't have problems rendering some pages I need to visit properly, I'd use it for more than verifying our websites look right on all browsers. I generally like Opera...
I know your post was taken as FUNNY, but I lost several hours last week installing, then uninstalling, an "important security patch" that took down the my client's Exchange Server. Had it been done automatically, the server would have simply stopped working for unknown reasons, at some MS-selected random time...
I, for one, do NOT look forward to the coming mandatory auto-patching, but I suppose it is inevitable with Microsoft.
I don't bother reporting individual incidents anymore (hundreds of different IPs per day), but, when one IP or subnet gets agressive about spamming, I do report it. For Verizon, I have started by sending an initial report, pointing out how many attempts have occured so far. An hour later, I send a second message, detailing the number since the first report. An hour later, EVERY message I get from my servers about the bounces gets forwarded.
Usually only takes 4 or 5 hundred such reports to get the IP blocked on their end... B-)
Part of the request exchanged between a browser and a http server is a list of encodings and languages accepted by the browser and user. Is there a way to modify popular browsers to send, say, "Pragma:no-spyware-accepted" and "Pragma:no-tracking-software-accepted" on each request, to indicate in advance that you do not accept such software, despite (mistaken) click-throughs?
Granted, no spyware company is going to pay attention to such things, but it might be useful if you participate in a class-action claim against such a company for installing damaging software on your system without your permission.
Postfix allows you to configure "don't accept without HELO/EHLO", "don't accept without FQDN in HELO/EHLO", and several other restrictions.
As for having the HELO match the domain of the envelope sender, well, that's tougher. We only host about 50 domains, but they all pass through two servers. Due to the way DNS works, it's not a "best practice" to list "mx.domain1.net" as the mail exchanger for "domain2.net" (although some major ISPs do it), so domain2.net might list list "mx.domain2.net", giving the same IP as "mx.domain1.net" uses. What should the mail server send as a HELO when forwarding mail for domain2.net?
We solved this by always having the mail servers send their own host names. All the domains claim their own FQDN mail server, with the IP of the consolidated server. If you do a MX lookup on the envelope sender, you'll get a matching IP with the sending computer. If you do an rDNS lookup, you'll get a matching host name for the HELO hostname. And, now, if you do an SPF lookup on the domain, you'll also get confirmation of the server's validity in handling mail for that domain. We're going to implement Microsoft's "CallerID for email" when/if we decide we can live with the license agreement...
Just validating HELO==rDNS or that the HELO matches the domain of the MAIL FROM is something the spammers have moved beyond already. Hundreds of times per day, I get things like the following:
HELO pcp03753391pcs.walngs01.pa.comcast.net
The rDNS on the IP matches the HELO command perfectly... but, it's not a valid mail exchanger for COMCAST.NET. Without additional help, all the spammer has to do is claim a MAIL FROM in the COMCAST.NET domain to get in, if you ONLY validate the HELO against the rDNS.
Right now, we have filters in place to block certain HELO/EHLO domains. We block any attempt to claim to be one of our servers, or any claim to be "aol.com" or "yahoo.com" (both use rDNS-matching FQDNs in their HELOs), but can't do that for HOTMAIL.COM or MSN.COM, because SOME Microsoft servers just send "HELO HOTMAIL.COM", just like the spammers. Grrr...
We try to indulge in the "best practices". All of our servers send out their FQDNs as part of the EHLO transaction. The FQDN sent resolves to the IP sending the mail. Where this has failed is where we don't control the reverse DNS... Something most ISPs won't let you do on a DSL, which some of our customers use.
Try to explain to SBC that the reason your server's rDNS doesn't match the FQDN is that their rDNS is wrong. I tried that, the first time SBC bounced mail from the server in question. I was told that DNS was my responsibility, unless I was willing to turn it entirely over to them... for an extra charge, and they still wouldn't fix the rDNS, if we did. The third time the second-level tech told me to "fix our own DNS", I requested that he delegate the rDNS for the 65.43.0.0/16 subnet to me, and I'd fix it in an hour!
(of course, the rDNS for some of the other IPs in that block might stop working right, but that isn't MY problem...)
it also has the effect that completely legitimate and well-behaving mail servers on the network cannot do so either
And most ISPs will work with you on this. I spent a great deal of time on the phone with one North Carolina wireless ISP this month, fixing a problem with a zombie on their network. They are relatively new to the spam fighting game, but willing to learn. I went over the pro and con arguments of wholesale blocking of port 25 traffic, and the need for unblocking access to certain servers for certain people.
In the end, they elected to block all port 25 traffic EXCEPT that going to their mail servers, and wait to hear from their customers if it were a problem. After a week, no human users noticed... But the zombie stopped calling our servers!
Make sure your email server knows a message can be delivered before accepting it. Many "enterprise capable" mail servers don't (or can't) check to see if an email address is valid until AFTER they accept it... and then generate a bounce message when they can't figure out what to do with it.
This is one form of an open relay... If I want to spam bob@anywhere.com, and know that bigcompany.net runs Exchange Server, I spoof a message FROM bob@anywhere.com, containing my spam message, and send it TO some randomly-selected address at bigcompany.net, such as notavalidemailaddress@bigcompany.net.
If your server knows all the valid addresses it handles messages for, it can reject the message during the initial handshaking - issue a 550 No Such User message after being told who the target is. If it doesn't know, well... It can't do anything but accept mail targeted for your domain, and hand it off to the delivery agent.
No, no, no! Just unplugging the cable isn't enough! If the computer is still in the same room as a hub or router, it's still in a "networked environment", so you can't install it there!
You must unplug it, take it out into the street, and install it there. And heaven help you if there's a WiFi access point in the area!
Interestingly, the "free" edition of AVG is limited to systems that are not networked in any way... Quoting the "important notice!":
IT CAN NOT BE INSTALLED IN ANY NETWORKED ENVIRONMENT!
Last time I checked, "Internet access" (email, web pages, etc.) involved a "networked environment", meaning that anyone who needs an antivirus product is excluded from running the "free" AVG scanner...
I have no problem with sending email to AOL from our non-megacorp servers. Of course, we've never sent stuff to AOL that was classified as "bulk email", and we have taken a few moments to incorporate Sender Policy Framework records into our DNS, in keeping with AOL's stated policy on SPF and "whitelisting", so your mileage may vary.
If an applicant shows you his/her certifications first, move on to the next person. If you have to ASK them what certifications they've received, move them to the top of the list, because they're not relying upon their alphabet soup to get them hired!
Thanks for the mirror list... but, the one US site with the 9.1 ISOs wasn't reachable, so I've been "enjoying" near dial-up speeds, downloading the ISOs from Brazil and Costa Rico...
NTFS doesn't have a 2GB limit, but the version of jigdo for Windows refuses to write more than 2GB files, exiting with a message suggesting you use Linux instead. Since cygwin simulates Linux under Windows, that's one way around the limitation, but I chose to go to a Linux box instead.
Why fight with Windows when you have a REAL operating system around?
The discussion is all moot, however, until/unless someone who DOES have the ISO files elects to run jigdo-file on them to create the.jigdo and.template files...
Granted, I've only run jigdo on two systems - Windows XP (which won't do DVD ISOs, because they say they can't write files larger than 2GB), and Mandrake 10. Both worked just fine, although it did take a long time to download everything.
What's especially nice about jigdo, though, is that building the next CD/DVD ISO in the release candidate chain will require a lot less downloading - if a file only changes position between two ISOs, it isn't downloaded again. Only a version change would trigger a package download.
Slashdot Mirror
Try touching up a map after it's been converted to a JPEG. It's not going to look good. Been there, done that, now I sell the T-shirts!
What I found was that, while Internet Explorer has the most problem with PNG, PNGs can be displayed in all 5.x versions, provided they have HTML wrapped around them. That is, you can't always get the picture if you try to display http://a.b/this.png, it would work if you had http://a.b/this.htm, and this.htm was nothing more than an IMG tag containing http://a.b/this.png.
I took advantage of this to replace all the "display a GIF" links to add navigation buttons to the new page. (Turns out that Mozilla has this restriction, too)
Since then, I've done a lot of work with dynamically generated graphics, and it's been almost exclusively PNG. My biggest problem has been that IE and other browsers ignore the pixels/cm size parameter of PNG, and assume that all graphics are 72dpi, just like GIF. One of my most-used graphics is a 1200x1600 300dpi "label", which should be a half-page when printed. It's 4 times that size if you let the browser print it... Except when I wrap it in an IMG tag that says to scale it to 600x800!
The security advisory then lists a dozen or so popular multi-stage relays, from some major ISPs. This explains why my system was being hit by Verizon servers over a thousand times this weekend, targeting a non-existant address.
And here I thought it was just their normal "ignore the 550 response code, just retry endlessly" configuration! Turns out, it was just their "Relay anything for anyone" configuration!
Frankly, I've switched to Money for one reason... it is possible to disable all advertising. I have not found an official way to do that in Intuit products, short of deleting the file that contains the ads... and that only kills 90% of them.
Inertia is all that stops me now from moving to a different (probably open-source) check register program. I've got Money 2000 tweaked the way I want it. But, if it decides to show me an ad again... BAM! To the moon! B-)
(the parent needs to be modded up, for those of you with moderator points!)
Had the patch been automatically applied, it might be hours discovering WHY the system stopped working, then time spent figuring out whether or not the patch could be rolled back (remember, some MS patches are ONE WAY!), then rolling it back... Assuming it didn't corrupt your data along the way.
Autopatching is likely to become the wave of the future, but I hope Microsoft allows you to manually override it. Maybe they can make it pop up a modal dialog box to confirm that you're ready for them to corrupt^H^H^H^H^H^H^Hpatch your system...
Unfortunately, that "one week ago" was the second story announcing the problem, and it was heralded as "redundant" for being a week old at the time...
The really unfortunate part of all this is that you can run a configuration like I do - treat all of internet as "restricted", disallow all scripting, don't trust any downloads - and not be vulnerable to something like this. My system's configuration requires that I tag windowsupdate.microsoft.com as a "trusted" site in order to get updates!
But it means that hundreds of common websites stop working. Microsoft decided to join the control of ALL scripting under a few settings. In order to stop the execution of untrusted Active-X controls, I end up disabling the execution of Adobe Acrobat, for example. And some versions of IE don't separate Javascript from Active-X when it comes from disabling scripting.
This isn't to say I'm really happy with how Mozilla does things. I would MUCH prefer it if I had the "trusted sites" concept in Mozilla/FireFox, because I could universally disable Javascript, yet have it come back on when I visit my own servers, or those vendor sites that need it. FireFox, at least, will allow quick access to the toggle-Javascript button, but Mozilla requires far too many mouse clicks to do it.
Opera has nice, fast access to scripting controls. If it didn't have problems rendering some pages I need to visit properly, I'd use it for more than verifying our websites look right on all browsers. I generally like Opera...
No, I try not to indulge in tired, worn-out phrases, like "tired, worn-out"... B-)
I, for one, do NOT look forward to the coming mandatory auto-patching, but I suppose it is inevitable with Microsoft.
I don't bother reporting individual incidents anymore (hundreds of different IPs per day), but, when one IP or subnet gets agressive about spamming, I do report it. For Verizon, I have started by sending an initial report, pointing out how many attempts have occured so far. An hour later, I send a second message, detailing the number since the first report. An hour later, EVERY message I get from my servers about the bounces gets forwarded.
Usually only takes 4 or 5 hundred such reports to get the IP blocked on their end... B-)
All televisions are depth challenged, no matter what their dimensions. You need only turn them on to see the problem!
Based upon much of the content of internet, I'd say the sewer portion would be bidirectional!
Granted, no spyware company is going to pay attention to such things, but it might be useful if you participate in a class-action claim against such a company for installing damaging software on your system without your permission.
As for having the HELO match the domain of the envelope sender, well, that's tougher. We only host about 50 domains, but they all pass through two servers. Due to the way DNS works, it's not a "best practice" to list "mx.domain1.net" as the mail exchanger for "domain2.net" (although some major ISPs do it), so domain2.net might list list "mx.domain2.net", giving the same IP as "mx.domain1.net" uses. What should the mail server send as a HELO when forwarding mail for domain2.net?
We solved this by always having the mail servers send their own host names. All the domains claim their own FQDN mail server, with the IP of the consolidated server. If you do a MX lookup on the envelope sender, you'll get a matching IP with the sending computer. If you do an rDNS lookup, you'll get a matching host name for the HELO hostname. And, now, if you do an SPF lookup on the domain, you'll also get confirmation of the server's validity in handling mail for that domain. We're going to implement Microsoft's "CallerID for email" when/if we decide we can live with the license agreement...
Just validating HELO==rDNS or that the HELO matches the domain of the MAIL FROM is something the spammers have moved beyond already. Hundreds of times per day, I get things like the following:
HELO pcp03753391pcs.walngs01.pa.comcast.net
The rDNS on the IP matches the HELO command perfectly... but, it's not a valid mail exchanger for COMCAST.NET. Without additional help, all the spammer has to do is claim a MAIL FROM in the COMCAST.NET domain to get in, if you ONLY validate the HELO against the rDNS.
Right now, we have filters in place to block certain HELO/EHLO domains. We block any attempt to claim to be one of our servers, or any claim to be "aol.com" or "yahoo.com" (both use rDNS-matching FQDNs in their HELOs), but can't do that for HOTMAIL.COM or MSN.COM, because SOME Microsoft servers just send "HELO HOTMAIL.COM", just like the spammers. Grrr...
Try to explain to SBC that the reason your server's rDNS doesn't match the FQDN is that their rDNS is wrong. I tried that, the first time SBC bounced mail from the server in question. I was told that DNS was my responsibility, unless I was willing to turn it entirely over to them... for an extra charge, and they still wouldn't fix the rDNS, if we did. The third time the second-level tech told me to "fix our own DNS", I requested that he delegate the rDNS for the 65.43.0.0/16 subnet to me, and I'd fix it in an hour!
(of course, the rDNS for some of the other IPs in that block might stop working right, but that isn't MY problem...)
And most ISPs will work with you on this. I spent a great deal of time on the phone with one North Carolina wireless ISP this month, fixing a problem with a zombie on their network. They are relatively new to the spam fighting game, but willing to learn. I went over the pro and con arguments of wholesale blocking of port 25 traffic, and the need for unblocking access to certain servers for certain people.
In the end, they elected to block all port 25 traffic EXCEPT that going to their mail servers, and wait to hear from their customers if it were a problem. After a week, no human users noticed... But the zombie stopped calling our servers!
This is one form of an open relay... If I want to spam bob@anywhere.com, and know that bigcompany.net runs Exchange Server, I spoof a message FROM bob@anywhere.com, containing my spam message, and send it TO some randomly-selected address at bigcompany.net, such as notavalidemailaddress@bigcompany.net.
If your server knows all the valid addresses it handles messages for, it can reject the message during the initial handshaking - issue a 550 No Such User message after being told who the target is. If it doesn't know, well... It can't do anything but accept mail targeted for your domain, and hand it off to the delivery agent.
You must unplug it, take it out into the street, and install it there. And heaven help you if there's a WiFi access point in the area!
B-)
Last time I checked, "Internet access" (email, web pages, etc.) involved a "networked environment", meaning that anyone who needs an antivirus product is excluded from running the "free" AVG scanner...
I have no problem with sending email to AOL from our non-megacorp servers. Of course, we've never sent stuff to AOL that was classified as "bulk email", and we have taken a few moments to incorporate Sender Policy Framework records into our DNS, in keeping with AOL's stated policy on SPF and "whitelisting", so your mileage may vary.
If an applicant shows you his/her certifications first, move on to the next person. If you have to ASK them what certifications they've received, move them to the top of the list, because they're not relying upon their alphabet soup to get them hired!
Thanks for the mirror list... but, the one US site with the 9.1 ISOs wasn't reachable, so I've been "enjoying" near dial-up speeds, downloading the ISOs from Brazil and Costa Rico...
NTFS doesn't have a 2GB limit, but the version of jigdo for Windows refuses to write more than 2GB files, exiting with a message suggesting you use Linux instead. Since cygwin simulates Linux under Windows, that's one way around the limitation, but I chose to go to a Linux box instead. Why fight with Windows when you have a REAL operating system around? The discussion is all moot, however, until/unless someone who DOES have the ISO files elects to run jigdo-file on them to create the .jigdo and .template files...
What's especially nice about jigdo, though, is that building the next CD/DVD ISO in the release candidate chain will require a lot less downloading - if a file only changes position between two ISOs, it isn't downloaded again. Only a version change would trigger a package download.