OK, I try to avoid being too off-topic in my blog entries, but this may be helpful info for others. Someone was lamenting how sad it was that Outlook users are so open to abuse via HTML email. I put together this reply and thought that perhaps my blog readers might appreciate some of the ideas:
As for outlook being a haven for spammers, well, it can be. But there are steps one can take. It's no longer enough to merely "not open attachments", as you note. Here are some steps:
As for outlook being a haven for spammers, well, it can be. But there are steps one can take. It's no longer enough to merely "not open attachments", as you note. Here are some steps:
1) Turn off View>Preview Pane, otherwise when you're looking at email in your inbox, simply selecting a message will cause it to be "previewed" in whole and will execute HTML in the page, thus triggering not only these IMG SRC tags you describe but also possibly executing code via <object> and other tags.
2) Turn on View>AutoPreview, so that you can (if you like) at least see a few lines of a message. Then, even if it's HTML it's not executed.
3) If a message looks suspicious, rather than open it (which will execute that HTML), do a couple of things. First, if the name listed in the "from" is curious, right click on the message and choose "options" to see the "internet headers" and scroll down to learn more about who sent it, etc.
4) If you're tempted to open it but don't want to risk the HTML "executing", there's one last trick. Use File>Save As. I do this all the time. By saving it off (choosing "text" for "save as type") you can then open that text file, and even if it had HTML, you could now look at the file without risk. Saving it as text, though, will cause it to be stripped of HTML as well. If you want to see if the message was an HTML message, you need to use "html" for "save as type". Just be sure then not to open it with IE or another
browser. Open it with Notepad, Studio, or another editor.
It's a real shame that Outlook (2000) at least doesn't make this last step easier.
Doing all these things will greatly reduce the risk of your being caught off guard. And, as Jorgen points out, by not even reading "spam" messages that might trigger those <IMG SRC> tags sending a toggle back to the server, you may lead them to think that they've reached a dead email address.
Thursday, November 21, 2002
Tuesday, November 19, 2002
Ratings in from my DevCon 2002 Presentation
I try not to do too much obvious self-promotion on the blog, but the evaluations are in from the DevCon and of the 71 attendees of my "Incorporating JSP Custom Tags in CFMX" presentation, I received an average overall rating of 4.6 out of 5 and several nice comments. More detail in the associated press release available on my site. Some of the kind comments included:
This is my third year presenting at DevCon and I'm grateful to Macromedia for allowing me another avenue to share with the community.
- Very well done! Good information clearly presented
- Fantastic. Presenter was very knowledgeable. Great overview - a bit fast presenting though!
- Managed to increase speed without losing quality (started late [due to earlier session running long])
- Charlie presents the material in a manner appropriate for all levels of experience
- Charlie is an excellent speaker. great presentation
- Charlie Arehart is always a good speaker no matter what he speaks on
This is my third year presenting at DevCon and I'm grateful to Macromedia for allowing me another avenue to share with the community.
Monday, November 18, 2002
Nice, simple, low-cost Version Control for Windows
Looking to add source code control to your application, but perhaps put off by the high cost of Microsoft Visual SourceSafe (VSS), or the complications of open source tools like CVS? If you're in a windows environment (only), take a look at QumaSoft's QVCS. It's quite easy to set up and use (includes a Windows interface for managing revisions), and also integrates with Studio/HomeSite (by way of their "project" feature).
If you've never used the projects feature or not set one up to work with Version Control, see Chapter 9 of the "Using HomeSite" book available online. It's the same process in Studio and HomeSite+.
If you want to use QVCS from within Studio/HomeSite, just be sure to first enable the "IDE Integration" feature in QVCS (under the "Admin" menu command). It doesn't seem to matter if you set it as what QVCS calls the "default" version control tool option.
Note also that in creating a "project" in QVCS (not technically the same as a Studio/HomeSite project, but they can both point at the same source code directory), QVCS offers a feature called a "reference copy" location. This seems similar to what VSS calls a "shadow" directory. If you're working in a team, this is a place where whenever you check-in files, they are copied both to the source code repository (called the "archives" in QVCS) in binary form as well as to this "reference" directory in text form, such as to act as the testing/integration directory for a team of developers.
I may put together a couple of movies showing how all this works, but besides the Studio/HomeSite help reference I gave you, there's also decent help in QVCS (including a couple of tutorial chapters in the Help as well as an available PDF of the entire help file), so most people should be able to take it from here. Enjoy!
(BTW, if you're wondering whether you can use this with Dreamweaver MX, sadly, it seems no. The feature in DWMX for working with VSS--in the "remote info" feature of a site--is really a direct connection to the VSS database, not to the SCC API integration such as is used by QVCS, VSS, and other source code tools. There seems to be no SCC API support in DWMX.
This isn't the end of the world, however. If you use DWMX, you can still benefit from using this or any other source code control tool. It, like others, offers its own interface for performing checkin, checkout, comparing files, reporting and lots more. Indeed, if DWMX is setup to be the default application to open the files you want to control--if double-clicking the file in Windows Explorer would open Dreamweaver--then double-clicking it in the QVCS interface will offer to check-out the file and then open it within DWMX. That's a reasonable compromise. You just then would go back to the QVCS interface to check the file/s in when done after saving it in DWMX.)
If you've never used the projects feature or not set one up to work with Version Control, see Chapter 9 of the "Using HomeSite" book available online. It's the same process in Studio and HomeSite+.
If you want to use QVCS from within Studio/HomeSite, just be sure to first enable the "IDE Integration" feature in QVCS (under the "Admin" menu command). It doesn't seem to matter if you set it as what QVCS calls the "default" version control tool option.
Note also that in creating a "project" in QVCS (not technically the same as a Studio/HomeSite project, but they can both point at the same source code directory), QVCS offers a feature called a "reference copy" location. This seems similar to what VSS calls a "shadow" directory. If you're working in a team, this is a place where whenever you check-in files, they are copied both to the source code repository (called the "archives" in QVCS) in binary form as well as to this "reference" directory in text form, such as to act as the testing/integration directory for a team of developers.
I may put together a couple of movies showing how all this works, but besides the Studio/HomeSite help reference I gave you, there's also decent help in QVCS (including a couple of tutorial chapters in the Help as well as an available PDF of the entire help file), so most people should be able to take it from here. Enjoy!
(BTW, if you're wondering whether you can use this with Dreamweaver MX, sadly, it seems no. The feature in DWMX for working with VSS--in the "remote info" feature of a site--is really a direct connection to the VSS database, not to the SCC API integration such as is used by QVCS, VSS, and other source code tools. There seems to be no SCC API support in DWMX.
This isn't the end of the world, however. If you use DWMX, you can still benefit from using this or any other source code control tool. It, like others, offers its own interface for performing checkin, checkout, comparing files, reporting and lots more. Indeed, if DWMX is setup to be the default application to open the files you want to control--if double-clicking the file in Windows Explorer would open Dreamweaver--then double-clicking it in the QVCS interface will offer to check-out the file and then open it within DWMX. That's a reasonable compromise. You just then would go back to the QVCS interface to check the file/s in when done after saving it in DWMX.)
Sunday, November 17, 2002
Enabling CFMX Metrics Reporting and Service Debugging
*** Updated 2/28/03 to change filename reference from jrun-web.xml to jrun.xml. Thanks to Rob Rusher for pointing it out. Originally posted 11/17/02 ***
Interested in logging how many threads are running within CFMX, or how many sessions, or how much memory (in KBs) is being used? There is a set of logging information that you can enable (it's disabled by default) so that it's written to the default-event.log file in CFusionMX\runtime\logs. To enable it, change jrun.xml in CFusionMX\runtime\servers\default\SERVER-INF, setting the <service class="jrunx.logger.LoggerService" name="LoggerService"> element's:
<attribute name="metricsEnabled">false</attribute>
to true. Another setting next to is is:
<attribute name="debugEnabled">false</attribute>
Setting that to true will add new lines to that log file, indicating (with a prefix of "debug") major events that happen in the establishment of the CFMX environment.
Of course, you want to think twice about enabling this sort of metric/debug reporting in production, as it will add some overhead. Still, it can be informative.
In the case of the metric logging, you will see that there are other lines that follow these in the jrun.xml that control the reporting frequency and details. You can learn more about these settings not in the CFMX docs but instead in the JRun docs, in particular the JRun Administrator's Guide, Chapter 7 on Connection Monitoring, available online at livedocs.macromedia.com, specifically at http://livedocs.macromedia.com/jrun4docs/JRun_Administrators_Guide/netmon2.jsp#1096147.
You'll learn there the various variables you can monitor about the CFMX server as a whole (memory and session tracking) as well as web server connection status (such as idle, busy, listening threads, and more). Unfortunately, while the mechanism for monitoring such threads with an external web server connection (like IIS or Apache) work as explained, doing the same for the built-in web server (saying to use the web. prefix for the listed variables) does not work in CFMX.
I'd welcome any insights from anyone in or out of MM with more info.
Interested in logging how many threads are running within CFMX, or how many sessions, or how much memory (in KBs) is being used? There is a set of logging information that you can enable (it's disabled by default) so that it's written to the default-event.log file in CFusionMX\runtime\logs. To enable it, change jrun.xml in CFusionMX\runtime\servers\default\SERVER-INF, setting the <service class="jrunx.logger.LoggerService" name="LoggerService"> element's:
<attribute name="metricsEnabled">false</attribute>
to true. Another setting next to is is:
<attribute name="debugEnabled">false</attribute>
Setting that to true will add new lines to that log file, indicating (with a prefix of "debug") major events that happen in the establishment of the CFMX environment.
Of course, you want to think twice about enabling this sort of metric/debug reporting in production, as it will add some overhead. Still, it can be informative.
In the case of the metric logging, you will see that there are other lines that follow these in the jrun.xml that control the reporting frequency and details. You can learn more about these settings not in the CFMX docs but instead in the JRun docs, in particular the JRun Administrator's Guide, Chapter 7 on Connection Monitoring, available online at livedocs.macromedia.com, specifically at http://livedocs.macromedia.com/jrun4docs/JRun_Administrators_Guide/netmon2.jsp#1096147.
You'll learn there the various variables you can monitor about the CFMX server as a whole (memory and session tracking) as well as web server connection status (such as idle, busy, listening threads, and more). Unfortunately, while the mechanism for monitoring such threads with an external web server connection (like IIS or Apache) work as explained, doing the same for the built-in web server (saying to use the web. prefix for the listed variables) does not work in CFMX.
I'd welcome any insights from anyone in or out of MM with more info.
Subscribe to:
Posts (Atom)
