Gregs reasons to NOT send images in the email body

Are you ready for my geeky-not-what-you-want-to-hear explanation?

1. Email was never designed to have images. Email programs have “retrofitted” them.
   
2. They increase the size if each message, sometimes 4-10x and more! When you are talking about a single signature that is 20k, that is 5-6x larger message size than what the message would be without it. And when you load your mail server with thousands and thousands of those, that can mean the difference of a slow or fast server. The difference is in mailbox size, scanning time, transfer and process time, database storage, backup time and space, and sending/receiving time. All being 5,6,10 times more than what they could be, just because you have a logo.
   
3. More and more people have images blocked by their email client.
   
4. More and more mail server scanners (for spam and viruses) strip out the images and HTML formatting because of security reasons. (because spam and viruses link images and HTML code to outside sources, loading things you don’t want in your system, and also verifying you exist and can receive more spam!) Which completely disallows the users ability to see the intended publication, which make the message sometimes appear out of order or jumbled around, completely obscuring the message. (which is only in text in the first place)
   
5. Email client programs can have any possible screen width for the message, making it impossible to correctly format a background and graphical body so that it looks correct for all users. This is way tougher than doing doing web pages, because at least on the web, you design for 800×600 screen size and larger. But email programs can be resized, and sometime very small.
   
6. Relating to the last item… When you design a template for sending messages in HTML (so you can have images) you are limited to the design capability of the email program. Not everyone has the same email program, and therefore the formatting will most likely be rendered incorrectly. (meaning, it’s not very portable, unlike PDF’s.)
   

Ok, so that’s all, as far as I know, factual, technical reasons to not use images in email. With that knowledge, it is my *technical* advice to not use them in the message body. On the other hand, they do make the message more attractive (usually). And they can help to “brand” the message. I can surely understand that.

Email is all about the *message* you want to deliver. And what you say is in the typed text. I have all my images blocked on my programs, so I can cut through the mumbo jumbo and read the actual message in my small preview pane. To me, it’s more professional to keep your message body as text, and attach any images you want to share. (including PDF invoices, with images on the invoice itself) And, it’s more respectful to the client that they receive the properly formatted, text message, then to be cute. To me it’s a matter of function-over-form, not the other way around. But, of course, now we’re are talking about *my opinion*.

A few minutes ago I ran into a blog by someone that said something that needed to be said. IT Certs are not really worth getting. I just wanted to save my comments on my own blog to reiterate and edit later.

Here’s my comments on his blog:

Having spent a few years as an IT Manager for a small company, I can say that I never looked at Certs in my stack of resumes. (Except maybe, A+, maybe) In fact, I put very little importance on College education. I wanted to see a couple years providing real, and creative solutions. This gave me a good ground work to start the interview process, and then determine if the personality would work.
I have seen a couple educated people, looking to get certs, not even be able to replace a hard drive. Or even tell me why certain DNS issues were causing problems. In my IT world, these people will never do. Learn how to do pc repair, then networking (the non-microsoft way too, ie. Linux) and you’ll be 100% better off.
In my experience getting jobs (and now clients), having the NT cert from back in 98, not a SINGLE person has ever asked me about it! I was always hired because of a referral, and my experience spoke for itself.
Besides, I feel that Certs really say, “I know the books smarts that this vendor wants me to know, not necessarily what the real world needs.” I would even say that, having the NT cert, only half of it was useful information.

I just listened to a podcast that talked about spam protection solutions and standards. As I listened I couldn’t help but think about the fact that standards dont work unless EVERBODY adhere’s to them.

As I run a business, I want to receive emails from my customers without issue. If I install some mail verification software, and my customer fails the verification because they do not run the software, my message will not be received. So… what good is the verification? None!

This is a super simplified example, but businesses will not subscribe to a technology that disallows customer contact. Believe me, I KNOW! I tried to implement something like relay blacklists to help combat spam, but it blocked client access once, and that was enough to lose $50,0o0 in sales. So as I said, unless every single mail server out there utilizes the exact same verification process, it will not be adopted, and in fact will be pointless.

I have to do some more research on this topic, so as you read this, note that it might be way off and there might be a valid solution out there. I am sure that the people working on this realize this problem, so hats off to those of you working in it for taking on this massive issue.

Before I get going, please comment on this. I am wanting more information, so please share.

I was wondering, though, why use a vpn to tunnel a terminal server connection? Isn’t terminal server encrypted already? Here’s a couple things that I *think* are important:

1. The vpn connection is no more secure than the terminal server. Why, if a trogan program runs on your remote client, what difference is it that you have a vpn to cover your terminal server? The attacker has access to the remote client, they now can get into your network with either system.
2. The vpn connection opens up a whole mess of insecurity if your remote client is compromised. (of course, it does with terminal server as well)
3. The data is never on the client if you use a terminal server, but with vpn, you open up your network. OUCH!
4. This is the one that really get’s me… with a vpn, if your remote client gets a nasty virus, your whole corporate network will probably now have it too once that vpn connection is opened. Not so with terminal server.
5. At least with terminal server, you can totally restrict apps and printing and such, so nothing is ever on the client, it only receives the screen shot of the server.
6. Brute forcing usernames and passwords are vulnerable on both.
7. If you were really worried about security… YOU WOULDNT RUN ANYTHING ON THE INTERNET! You wouldnt run IIS, Email, or anything else that communicates on the internet, expecially remote access services!

So from where I sit, I can’t understand how using vpn to tunnel terminal server will make my remote access more secure, in fact, possibly less secure. Please tell me if I am missing something though.

Thanks.

Greg

———————————–
Edit: 3/28/05

I have been talking about this issue with friends on forums, and I wanted to share more thoughts based on some of my posts. And just so you keep this in mind, I am basing these thoughts in the context of a small business with less than 50 users which might not even have an IT staff. A company like this typically will not spend $10-$15 thousand dollars on a VPN solution, leaving us with only the built in Microsoft technologies (or linux).

— from a post on 3/21/05 —

I dont think that vpn is less secure really, its got a great security model. What I think is less secure, is using vpn with TS. I dont believe it offers any additional protection. Why encrypt an encrypted connection? Why give access to the whole network and all the servers, if you only want them to access a few apps on 1 server? And why I think it’s less secure to run it this way? That is because the reason you run Terminal Server is to allow the user access to certain apps that would not otherwise run on a vpn, AND to isolate the use of those apps and their data. You cant isolate the processing of data and its transmissions on a vpn. The vpn essentially extends the internal network to a remote system over a public network, right? Well a TS client does not do that. It only extends the keyboard, mouse and graphics. So the data never leaves the network, it cant even be printed remotely or cut&pasted on the remote client (if you set that up of course).

So it’s not that I think vpn is less secure, implemented properly, it’s great, but only for the right purposes. For my systems, vpn wont work. I have to run apps that just wont run over a vpn, or they will but be so damn slow it just isnt practical. I installed vpn originally aboot 5 years ago at my largest client. We ran into many hurdles running our main apps. I basically determined that unless you have at least a 10 Mbit connection, dont bother. That’s not to say that apps cant work on vpn, it just depends on if they were written for it for one thing, and if not, how their execution and data is transfered. I have ran several apps that are so called ‘network’ apps, and all they do is put on a short cut to a large exe that is downloaded locally and then executed. That just wont work on vpn. It’s WAYYY too slow! Try running a 100mb + ms access mdb from remote vpn client, that then connects to a 3Gb + sql server db. Even on the fastest broadband connections, it just isnt feasible. Terminal Server solves that problem.

Now, also keep in mind, mostly why I have the ts’s is to do remote admin. Some companies have this setup: 2 servers, both are AD servers. One runs Exchange and IIS, and has MS ISA firewall on the server to vpn into and proxy out. (I didnt set that up, nor do I maintain it, I would have set it up way differently) The other server is behind that firewall and runs only a sql server internally. In this scenario, they didnt setup a dedicated firewall, and consequently are vulnerable from other sources that would put the domain controller at risk. This is because, it’s way more likely that IF an attempt were to be made to crack that server, it would be most open to attack on the IIS services, or Exchange. Once in, the firewall is useless. So… why put in the vpn here? There are so many WAY more insecure elements involved. This is why I mention in the blog… “if you’re worried about security, dont get online.” I mean, obviously your not THAT worried, or you wouldnt setup the systems that way. And if you’re not THAT worried, why use the VPN?

If I were to make the network more secure for remote admin I think I’d have to do this: Run a TS in a DMZ with admin rights to TS denied. (have to be a restricted use user acct.) Then, from the TS session, open another TS session to the specific server you want to administer. Your firewall can be set to allow communication on TS traffic to and from the dmz computer only. This way, no data is ever really sent to the remote pc, and the remote pc has not direct access to any internal system, but does have access to *view* information.

The insecurity I see, with both TS or VPN, is the client use and it’s vulnerabilities. They both suffer from the fact that IF some trojan is somehow executed and allows an unauth user remote control of the pc, that user could see all the data your company user can see. The advantage to TS in this situation, is that at least that ‘hacker’ would not have direct access to the whole network right from start. They could obviously run a keylogger and then log into that TS themselves, or from the remote pc. Same with the vpn. In my situation, the remote users use their own systems to remote into the company. They wont spend the money, nor do they have the administrative capability to maintain stringent policies and systems.

— Posted from 3/23/05 —

I found out that TS can be brute force attacked! (via password crack) (OH NO! VPN IS NEEDED!!) BUT!!!! Then I did a little more research and discovered that with my setup at my different clients, it aint gonna happen.

There is a program out there that can “dictionary attack” a Terminal Server. Not Brute Force it. There’s a difference. Dictionary attack uses a dictionary of words to test, brute force checks every letter combinatoin. That program must rely on the fact that the local “administrator” account always has local accees to the TS. And since it uses only a dictionary attack, dont use words for a password, it wont crack it. And since it relies on the admin account, rename the administrator to something else, problem solved.

Use of an 8 or more character password is also all that is needed to deter an actual brute force attack. Along with account lockout policies when logons fail, you can pretty much bet that you wont get brute force cracked. I read somewhere, that if you use 12 character passwords, and if they are only lower and uppercase, there are almost 400 BILLION BILLION combinations. And even if you could do 1 million attempts per second, it would take millions of years to crack! I am sure someone good at math can figure the details out. And this is all for just the password, YOU NEED A USERNAME TOO! Add lockouts to the mix, and it aint happening! Do some research on brute force cracking and you will see what I mean.

I read a post by someone who cracked a 6 character password with special characters in it, it was cracking something on the local machine (not networked then) and it took a day and a half to do it. Try doing that on network systems, where, if properly setup, will not allow millions of connection attempts like that.

I used to fear the “brute force” thing. Not now. And it’s not that it isnt possible, but properly configured networks/systems simply make it way too long to attempt it using current proccessing technology. that’s why higher bit encrytion is better. It takes way too much time to crack the encrypted key at 128 bits. By the time you did, the key would have changed.

Dictionary attacks are another thing, they can get a crack in minutes. But if you dont use dictionary words as passwords, then you are safe.

this all leads me to the essential wisdom of work, why do things the hard way. A hacker isnt going to try and crack something that is hard to get into, they will try the easiest route. TS and VPN are not easy to get into. They will look into which services provide the most exploits that are available to them. VPN and TS have very little exploits. (at least it was tough finding any) Try looking up exploits on your mail server or web server! I bet they’ll try getting in there way before an attempt on TS.

The amount of time involved to make these kind of attacks are huge. Script Kiddies or whatever arent going to spend that kind of time. The only way someone would do it is for money. And most likely a compititor might want the information and pay for the hacker, but holy cow, is that likely? I dont think so. It would be way easier to do some “social engineering” to infultrate the company and then get into the network.

Simple precautions on the TS are all that is needed. As with any service. 1. dont show the last user logged on. 2. restrict access to only certain users, not domain admins. 3. lockout failed login attempts. 4. long passwords 5. Change the admin name.

So I am still back to my original thought, vpn would not make ts more secure. It would only add more maintenance and head ache. But, if I already had a good vpn solution, I would utilize it.

However, I have a new thought, I guess. VPN, in certain situations that dont have stringent policies and procedures, would make remote access less secure than TS. This is because that encrypted tunnel does not get filtered by a firewall or IDS and a virus or attacker can use that connection to directly affect the entire network. With TS it is at least not possible. That’s why you have to have IT setup the remote computer and on it, restrict user actions as well. This makes VPN unattractive to me.

— and another post on 3/23/05 —

So when adding a vpn to tunnel a TS, what you are saying is, “I have a vpn, I need to tunnel it through another vpn to be more secure.” That’s like saying, “I need 2 firewalls to double up on the packet filtering.”

The only thing I think a vpn will do, and only if I had a nice hardware appliance type one, is give me device authentication. If I use MS software based vpn, especially using pptp protocol, I am no better off. I would still need to authenticate in either system (ts or vpn) and the hardware solution probably allows for IP or other device authentication. Also, I think that to really be secure you would need to use a certificate or something of that sort to authenticate. TS cant do that, so I would see that as an advantage in vpn.

If I put in a vpn, I open my whole network up. And with no real IT staff to monitor it or the client machine, that opens a whole mess of problems. At least with TS I prevent any openning of the network, only that port on that server. (no data is transfered, just user IO)

—————————————-

In my situations, as in small businesses remote administration, I do believe VPN is openning a hole in the network and making it a little less secure than to provide straight access to Terminal Services. So far I have not seen any evidence to tell me otherwise, but if anyone out there can give me specific reasons to give me some evidence, please do.

In 2002, I saw an article on Devshed.com about Zope. What they described intrigued me greatly. The whole “Everything’s an object” idea was fascinating. I proceeded to www.zope.org and downloaded Zope version Soon, I was in heaven as I discovered a new passion.

Before I get into this too much, you should know that I am not a Software Engineer. I am not an educated person. I have no formal training or computer science degree. Everything I have learned regarding programming, I learned on my own using books, the Internet, and practice. The thoughts I express here are strictly based on my own observations, opinions, and desires.

I originally started web design learning HTML and Javascript, of course, but soon realized the importance of server side code. So I ran into ASP and coming from a little experience in VB 6, it was easy to pick up. Then I found Zope. As much as I liked and enjoyed working in ASP/VB, I still found some tasks to be a little cumbersome. After testing Zope, it just made sense. For about 2 years I worked in ASP off and on, then about 2 more years in Zope.

This isn’t a story about why I switched from ASP though, it’s about not using ASP.NET. I purchased VB.NET 2003 in the summer of 2004. For six months I worked with web forms in .NET. After that, I concluded that it was better for me to use Zope. The keywords here are “better for me.” I gave ASP.NET a shot because I wanted to be sure I was working with a good platform for me and my clients. Doing so allowed me to compare what I learned in the previous ASP and in Zope. (From here on out, I will call ASP.NET, .NET.)

.NET is a great platform, and it’s very powerful and capable. It’s also very widely used and has a huge community of support. I really can’t say anything negative about it, except that it is too big and complicated. The things I might say that are drawbacks, are not necessarily negative as all platforms or environments have drawbacks. One drawback in .NET is the size of it. Many times I have found myself drowning in the overload of information and NOT finding what I wanted. Another drawback would be, from a web development standpoint, deployment. Deploying web applications in .NET is a pain. You cannot simply copy your application directory from a test server to the production server without running into path issues, or maybe some odd configuration at the ISP’s IIS server. As a result, when my clients want a simple change, I put them off because I have to do so much more work just to test some code and publish it.

I love the Visual Studio IDE and Intellisense. (That is what it is called, right?) Also, having the full procedural language, and having it separate from the HTML code is nice. Although, I have since learned that I like the integrated DTML mixed right in with the HTML better, but that is really only my preference. (Sounds like another blog to write)

In .NET, the compiled code is a benefit because even as complex and bulky as the .NET framework is, it is quite efficient during runtime. (for those uninformed, in .NET you must compile your code. In the older ASP, you simple edited the text file and ran it.) This compiling of code is partly a blessing for its runtime speed, but during development and deployment, it’s a curse. It just slows you down.

I would suppose in a large scale, corporate application, the compiling of code and separation of code and presentation is a benefit. And I suppose that the .NET framework would work better for web applications with thousands of concurrent users. But, that’s not what I do. That’s not what my clients want or need. My clients have less than 100 employees. (way less) 99% of what they need does not require the full scale, bloated capability of .NET. In fact, actually in my opinion, I believe that everything a small business would need for web applications, can be accomplished using Zope with the same performance as .NET, overall. Though you might find some things are faster in .NET, some are faster in Zope, so *overall* it’s a wash.

Concerning the speed of development, I would have to say Zope is faster, *overall*. There are some things that are faster in .NET as Microsoft has done a decent job helping the developer along with several pre-built objects. The problem is that when you want to customize the pre-built objects you run into problems trying to figure out how to use them in your own customized way, and since you almost always need to customize to suit your clients’ needs, that slows down development time greatly. So in this respect, I would have to say Zope is faster to develop in, but not in all cases as I have mentioned.

One of Zope drawbacks is that in order to work with it and be efficient you have to understand it. You have to *get* it. There are some concepts you have to understand. I suppose that’s no different in learning things like database design or programming in general, so maybe it’s not really a drawback after all. The concepts I am referring to here are really the relationship between DTML documents and DTML methods, and all other objects in the Zope database. But that is the beauty of Zope isn’t it? Zope is an application server that is really a database serving web objects. Everything in that database is just that, an object. How they all relate is the magic. It’s magic because they give you this framework to build upon, you take all the objects, design them and piece them together, and BAM you have an application.

During development, you inevitably run into code that needs debugging. I am split on this one. .NET is pretty good for debugging code. It has nice call stacks listed if you want and of course the IDE helps by allowing you to step through the code and see what your variables contain during runtime. Zope also has tracebacks and error logs allowing you to find an error. Neither platform has improved my development process enough over the other, so I would have to say it’s a tie.

Management. Zope is hands down, no contest, the winner here. .NET, as I stated erlier requires some tinkering to deploy and the code requires compilation when changed. This is a real pain when you want to move fast. The Zope server is easy to manage and quite reliable. The objects you create and develop are easily imported and exported and moved around making deployment a snap. In addition to all this, if you want to make a fast text change on a site, heck even a quick coding change, you simply log into the Zope Management Interface from any web browser on the Internet and make your changes. The changes are immediately available and if you just happen to need to revert from those changes, Zope has versioning built in and you can rollback the changes.

DTML. There are many people out there who would say DTML is no good. I completely disagree, particularly from a small business perspective. That’s a whole other debate and blog, so from my perspective and keeping with the relevance of this article, I will keep this simple. DTML allows you to easily create your application around your HTML and provide dynamic content. It looks like HTML, in fact I would describe it as super-charged HTML that executes on the server. .NET separates your code from your HTML. If you like that, or need it in some cases, then Zope is not for you. (unless you use ZPT, but I don’t) Because DTML is mixed within your page content, it’s quite easy to follow. This in turn speeds my development time.

.NET might have a full-blown development environment giving you a lot of power, but Zope does have Python scripts, and if so desired, external methods and products. Because of this, I wouldn’t say .NET has any additional capability over Zope. I am not a computer science guy though, so someone might argue that this is not true, but from my perspective, and for my clients needs, it is true.

.NET does not have or run an object database or use acquisition. This is what gives Zope its power. And again, someone might argue that Zope’s acquisition is no good, but for me, it rocks! I haven’t had any problems with it. It’s just one of those things in Zope that need an understanding of the concepts of object relationship.

.NET needs Windows. Not that this is bad, but limits options and makes it more expensive. I like options, makes it more useful to my clients. But, you should know, my favorite server setup for Zope is to run it on Windows 2000 or 2003 with Microsoft’s SQL server using the Egenix Zope DA for ODBC. With version 8 of Postgresql, I might be moving towards that though.

Zope connects to any data source I have thrown at it, and it will run on other platforms than Windows. (Linux) On a downside, Zope needs a licensed ODBC adapter on Windows if you use Zope 2.7 or higher, and on Linux you need licensed ODBC if you want to connect to Microsoft SQL server. This is not true when using MySQL or Postgresql on Linux, there are free database adapters available.

Well, let’s recap. I’ll list the pros and cons as I see it and how they fit with my needs.

Zope Pros

• I love DTML and how there is no separation of code and content.
• Python scripts, external methods, and products.
• Easy to manage and deploy. Nice Zope Management Interface useable from any web browser. This also makes quick updates, actually quick.
• It can do everything I need and ASP.NET provides me with no feature I need over the features of Zope. In other words, for my needs, Zope can do anything .NET can.
• Easy to learn.
• Easy to extend.
• Runs on Windows or Linux.
• Object database with custom object properties and acquisition.
• No compiling of code.
• Extensive database connectivity.

Zope Cons

• No IDE. This would be nice, but since it’s quite easy to use a decent text editor connecting to FTP or WebDAV, it’s not needed.
• Debugging could be a little better, but I don’t really have problems with it. Tracebacks and event logs are easy to use.
• Need a licensed ODBC adapter for running with MS SQL server. You need this with Zope 2.7 and higher, it’s worth every penny, but would be nice if there was newer, free one available.
• Not as widely used as other technologies. (Zope server use on Netcraft.com has doubled from 2/04 to 2/05 though, so that’s nice)
• Documentation is a little lacking. (this is getting much better though)

.NET Pros

• Nice IDE for development. Even the Web Matrix IDE is nice, but I much prefer the Visual Studio one. At about $100 for the Standard version of VB.NET, I can handle it. (but that wont connect to the full SQL server, you need to use MSDE)
• Nice debugging. This is partly due to the use of Visual Studio though.
• Great for enterprise application development with many developers.
• Many pre-built objects for development.
• Huge user base.
• Tons of documentation and usage examples.
• Full VB or C# language available. (or others too)

.NET Cons

• Too much information, too big. It’s often easy to get lost when trying to find a solution. This is a huge problem for me. When you do actually find the items you are looking for, it’s got pretty good documentation though.
• Deployment is a pain.
• Code needs to be compiled. (makes deployment harder as well as other things)
• Quick updates are a pain, because of the compiling of code.
• Pre-built objects are nice and are documented fully. Well, not fully, because if you need to do something customized, which you always do, then documentation is lacking. This is a big deal to me because trying to customize something takes way longer than it should. So, this is a con.
• You must use Windows.
• No object database or acquisition.

Just to be a little more complete too, here is why I don’t use ASP. (The older ASP)

• No object database and acquisition.
• Database operation is a little more of a pain. Not that it is not doable, just more difficult.
• SSI is available for dropping in code objects, but not anywhere near as nice and easy as using Zope DTML Methods or Python Scripts.
• While it is easier to deploy than .NET, and updates are quick, and it’s not compiled, there is no easy management interface and it’s not easily done from any web browser. Again, it’s just easier in Zope.
• The code is sort-of integrated and useable like DTML, but DTML is way easier, particularly when using databases.
• I wouldn’t say that ASP is exactly extensible.
• The thing I really don’t like about ASP though, and this is completely based on my own experience, it is slightly unreliable and the code is slightly slow and clunky when running.

I hope this information is helpful to someone out there. This isn’t ment to be disparaging to Microsoft or ASP and ASP.NET, it’s just that Zope seems to fit with my preferences and needs. .NET is great, and I have a couple clients that will continue to use .NET so I’ll keep using it, but if I can help it, I’ll use Zope.

Enjoy!

Greg Fischer
1st Byte Solutions