RBL's - are they really worth it?
I just added some new feeds to my RSS reader (which happens to be Outlook 12 right now) and I happened to notice a blog on Ant Drewery's blog from a few weeks back which talks about something that I feel strongly about - namely RBL's. For the most part, I despise them. Why? One main reason. Unless you build and maintain your own RBL (which I'd submit is just fine), YOU have no (or very little) control over WHO gets listed or how they (or you) get off. Let's face it - some of the folks that maintain some of the public RBL's that are available just don't care. Others want money in order to de-list you (when you get listed for some off-the-wall insane reason that no one in their right mind would do).

I understand the fight against spam - I really do. I sympathize with companies that are burdened with a lot of spam. It can get very nasty. However, working in the e-mail field, RBL's affect a lot of things negatively, and are very often used indiscriminately by novice admins. You try explaining to your CEO why that 2 milion dollar deal can't be sent to a customer because the customer uses a RBL that has you listed on it...

I am a very strong proponent of anti-spam, but using RBL's isn't a method that I encourage - at least not to BLOCK e-mail. Use RBL's as a way of increasing the spam score of an e-mail, but don't block using them. Use SPF/SenderID as a way of increasing the spam score of an e-mail, but don't block based on missing/incorrect SPF/SenderID records. Use Reverse DNS as a way of increasing the spam score of an e-mail, but don't block based on missing/incorrect PTR records. Now blocking e-mail for invalid e-mail addresses? That's another story. I'm all for doing that. :-)
- posted by Ben Winzenz @ 2:06 PM 0 comments

 
Exchange 12 64-bit only information
Terry Myerson goes over a few of the reasons why Exchange 12 will be shipping in 64-bit only code. The reasons make sense. I know there will be many who second-guess this decision and will say that it will prolong or delay the adoption rate of E12 by many companies. Initially, I thought the same thing, but I'm not so sure any more. It's all too early to tell anyways, as the RTM for E12 is likely more than a year away.
- posted by Ben Winzenz @ 1:24 PM 0 comments

 
Sometimes the easiest problems are the most difficult
I work a lot with our developers and QA folks. Heck, I maintain all of their environments, so I have to work pretty closely with them. Most of the problems that occur are fairly easy to fix, but I had one crop up today which absolutely stumped me for a while.

The environment is a 2-node Exchange 2003 Active/Passive cluster. It was reported to me that all of a sudden after a failover, something in the cluster wasn't working, and it was preventing QA work on that cluster. Because one of the cluster resources was failing, they couldn't use our product to manage/fail over the cluster. OK, I say, I'll have a look.

So, I RDP to the server and look at Cluster Admin, and I find that the Message Transfer Agent resource is failing to come online. Let's see what happens if I just try to bring it online. Bzzzzt - thanks for playing. Ok, so I check the event logs. I see a Event ID 9400 for the Exchange Virtual Server saying that it is unable to open a particular file. That's odd. Ok, there has to be a KB article relating to this. Sure enough, I find http://support.microsoft.com/default.aspx?scid=kb;en-us;154385, which tells me that the file may be missing or corrupt.

So, I look in the c:\program files\exchsrvr\mtadata directory, thinking that I'll find that the specified file isn't there and it will be an easy fix. Well, it's present in the directory, so I decide to replace it. Copied it from the CD, removed the Read only attribute (that is important!) and tried to bring the resource online. No joy. I went around and around for a while, even replacing ALL of the files in the mtadata directory from the CD. Still doesn't work. I had put it on hold for a while and decided to look some more this evening. Oddly enough, it was a KB article written for Exchange 4.0 of all things that allowed me to figure out the problem. http://support.microsoft.com/default.aspx?scid=kb;en-us;162384 discusses a series of steps of how to troubleshoot MTA failures. One of the parts of the article talks about checking the parameters section of the registry associated with the MTA. HKLM\System\Current Control Set\Services\MSExchangeMTA\Parameters is where it's at. As soon as I looked at that, I spotted 2 values that didn't look right. The MTA Database path and MTA Run directory both pointed to another drive.

When I looked at the directory that those 2 values pointed to, I noticed that there were some missing files. I didn't have time or the desire to find out at that point how they became missing, but I was able to solve the problem by copying the files from the c:\program files\exchsrvr\mtadata directory to the directory specified in the registry. Once I did that, I was able to bring the MTA resource online and was able to successfully fail the cluster over to the other node and have the MTA resource come online as well.

Lesson learned: Don't forget to check the basic stuff. If I would have thought to check the registry, I probably would have saved a lot of time trying to figure out this problem.
- posted by Ben Winzenz @ 9:25 PM 0 comments

 
Funny story about Hotel wireless

Just read a story on one of my other feeds about a guy who is a network
security engineer was having troubles with a very slow hotel wireless
internet connection. The problem, he found, was that someone else was
using a P2P app and hogging all the bandwidth. Read here about his creative way of getting this guy
off the network.

While I probably wouldn't have done this, it's still pretty funny,
whether it is true or not...

- posted by Ben Winzenz @ 8:58 AM 0 comments

 
Enabling SMTP Tarpitting in Windows 2003

It's no secret that Windows 2003 now includes a mechanism to enable SMTP
Tarpitting. Tarpitting is, in short, delaying the response (5.x.x
response, specifically) your server sends after a certain number of
invalid RCPT TO: commands. With each invalid name submitted, the delay
will grow longer. What does this accomplish? It makes e-mail
operations more expensive for spammers. Why? They thrive on the
ability to send as many e-mails as possible in a given period of time.
If you make it so they can't send as many e-mails, the operations become
more expensive. Does it stop them? No, but it may thwart their efforts
a bit, especially in sending spam to *your* domain. Now, in order to be
useful, you have to enable Recipient Filtering, and specifically, the
option to "Filter Recipients who are not in the Directory". This is
really the only way that tarpitting will work, because with the
recipient filter enabled, Exchange will issue a 5.1.1 response
indicating "User Unknown". Tarpitting delays those 5.1.1 responses.

Another reason that tarpitting can be very useful is to prevent
Directory Harvesting Attacks. If you simply enable recipient filtering,
it's possible that a spammer can harvest your list of users simply by
brute force spamming your domain. Since invalid users would immediately
generate the 5.1.1 error, it wouldn't be that hard to make a list of
those addresses that are valid. I'm sure that it would take a bit of
time to accumulate that list, but what do they care? By implementing
tarpitting, you make the likelihood of someone successfully harvesting
the list of users much less likely. It doesn't make it impossible, but
much less likely.

http://support.microsoft.com/?id=842851 describes how to implement SMTP
Tarpitting in Windows 2003, but what it doesn't mention is that in order
to use tarpitting, you actually need to have a hotfix installed. That
hotfix is mentioned in http://support.microsoft.com/kb/899492. While
KB842851 has a link to this article, there is nothing that states that
you need the hotfix. This hotfix is actually included in Windows 2003
SP1, so if you don't want to call PSS and ask for the hotfix, simply
make sure that you are running Windows 2003 SP1.

- posted by Ben Winzenz @ 10:01 AM 0 comments

 
So you want to change the location of IIS files or directories with Windows 2003?

How do I do that, you ask? Well, it sort of depends on what you need to
change. It also depends on whether you have Exchange installed. Let's
assume that you do for the purposes of this exercise, though I'll
include information on how to change them if you don't.

Changing SMTP information:
Some of the SMTP locations can be changed from within Exchange System
Manager. These include the Badmail Directory and the Queue directory.
To change these 2 locations, simply navigate to the Server, Protocols,
SMTP, Default SMTP Virtual Server and go to the properties. Then, go to
the Messages Tab. You will see locations where you can browse and
select the directory for the Badmail and Queue directories. However,
this doesn't allow you to change the Pickup directory. While there may
not be much need to change it, you may still want to for the sake of
organization. For a server that has Exchange installed, this
information is stored in Active Directory, and as such, should be
modified there rather than in the IIS metabase.

Exchange uses a documented process called DS2MB (Directory Service to
MetaBase) to replicate information from Active Directory (such as
Default Domain setting on Exchange Virtual Server, etc.) into the IIS
Metabase. If the SMTP Pickup directory is modified using MetaEdit
(Windows 2000) or by modifying the XML file (Windows 2003), it is
possible that the DS2MB process will overwrite those values with those
that are stored in Active Directory. For this reason, as a rule of
thumb if the attribute is stored in Active Directory (as well as the
Metabase), it should be modified in Active Directory.

http://support.microsoft.com/?kbid=822933 (How to change the Exchange
2003 SMTP Mailroot folder location) is a good reference for this for
Windows 2003/Exchange 2003.
http://support.microsoft.com/kb/318230/ (How to change the Exchange 2000
SMTP Mailroot directory location) is the Windows 2000/Exchange 2000
version.

Note that both articles reference rebooting the Exchange server at the
end. I don't think that step is actually required, and would prefer not
to restart a server, but I leave that to your discretion.

What if you don't have Exchange installed?

If you recall, with Windows 2000 (IIS 5.0), if you wanted to modify this
information, you had to do this with MetaEdit, which allowed you to
directly modify the IIS Metabase (Metaedit looks similar to a registry
editor). Well, with Windows 2003, MetaEdit is no longer necessary.
Now, the entire IIS metabase is stored in an XML file (yes, that's
right, XML). This XML file is located in the
c:\windows\system32\inetsrv directory and is called metabase.xml. Just
open it with your favorite text editor (I prefer EditPad Lite or Notepad2, both free for personal
use, and much more functional than notepad itself) and if you scroll
down far enough (or search for it), you will see information such as
below. The IIsSmtpServer Location section contains information related
to each SMTP Virtual Server. The first one is, aptly enough, instance
1, thus the SmtpSvc/1. Under there are several options. One of them,
shown below, shows the Pickup Directory. The example shown below makes
reference to Exchange, so the path would be different on a standalone
SMTP server. Simply make the change, save the xml file, and restart the
appropriate service(s), or perform an IISReset. Or, if you are brave
:-) you can enable direct metabase editing, which will apply the changes
on the fly. Note that even on standalone SMTP servers, some information
may be available to modify using IIS Manager, but if you are going to be
changing several values, it may be easier to simply modify the XML file.

IIsSmtpServer Location ="/LM/SmtpSvc/1"

Name="PickupDirectory"
ID="36880"
Value="C:\Program Files\Exchsrvr\Mailroot\vsi 1\PickUp"
Type="STRING"
UserType="IIS_MD_UT_SERVER"
Attributes="NO_ATTRIBUTES"

Changing NNTP information:
In the same XML file, you'll find the NNTP Virtual Server Settings.
While most people running Exchange probably don't configure NNTP, if you
do, you may have a desire to change this information. Keep in mind that
by default, NNTP newsgroups are actually stored in Public Folders, so
you won't find them in a local directory. As with SMTP, if you find any
of these settings in Exchange System Manager, or in Active Directory,
they should be modified there rather than the IIS Metabase. I believe
you'll find the virtual directory information within Exchange System
Manager, but I didn't see much else.

IIsNntpServer Location ="/LM/NNTPSVC/1"
AllowControlMsgs="FALSE"
ArticleTableFile="C:\Inetpub\nntpfile\article.hsh"
GroupHelpFile="C:\Inetpub\nntpfile\descrip.txt"
GroupListFile="C:\Inetpub\nntpfile\group.lst"
GroupVarListFile="C:\Inetpub\nntpfile\groupvar.lst"
HistoryTableFile="C:\Inetpub\nntpfile\history.hsh"
ListFile="C:\Inetpub\nntpfile\listfile.hsh"
MaxConnections="5000"
ModeratorFile="C:\Inetpub\nntpfile\moderatr.txt"
NTAuthenticationProviders="NTLM"
NewsDropDirectory="C:\Inetpub\nntpfile\drop"

NewsFailedPickupDirectory="C:\Inetpub\nntpfile\failedpickup"
NewsPickupDirectory="C:\Inetpub\nntpfile\pickup"
PrettyNamesFile="C:\Inetpub\nntpfile\prettynm.txt"
SecureBindings=":563:"
ServerAutoStart="FALSE"
ServerBindings=":119:"
ServerComment="Default NNTP Virtual Server"
XoverTableFile="C:\Inetpub\nntpfile\xover.hsh"

IIsNntpVirtualDir Location ="/LM/NNTPSVC/1/ROOT/_slavegroup"
Path="C:\Inetpub\nntpfile\root\_slavegroup"
VrDriverProgid="NNTP.FSPrepare"

IIsNntpVirtualDir Location ="/LM/NNTPSVC/1/ROOT/control"
Path="C:\Inetpub\nntpfile\root\control"
VrDriverProgid="NNTP.FSPrepare"

Changing Website information
Ok, so we've talked about both SMTP and NNTP. How do you change the
directory for the Default website? That's quite a bit easier. Simply
open IIS Manager, go to the properties of the default website, and
modify the Home Directory to point to the new path you designate.
Though you are prompted to specify the location of the Home Directory
for all new websites created, this same method applies to any websites
that you may want to move to another volume. Don't forget to copy the
contents of your old website to the new location prior to changing it in
IIS Manager :-)

Worth noting is that you need to be careful of any changes that might be
propagated to virtual directories underneath the website.
Exchange-specific virtual directories correspond to special locations
that you don't want to change :-)

- posted by Ben Winzenz @ 10:14 AM 0 comments

 
Do you want to open a hidden mailbox or send a message to a hidden mailbox?

There are really two ways that you can accomplish this.

Method 1:

Unhide the mailbox/user account, wait a few minutes for replication,
then add the account under the Account options (Tools, E-mail Accounts,
Change, Advanced, Add additional mailboxes). This would for obvious
reasons also allow you to send a message quite easily to the now
unhidden account. The only exception here is if you are using Outlook
2003 with cached mode and using the Offline address book, it would
require a rebuild of the offline address book (and re-download of OAB)
in order to get it working.

Once you have added the account to Outlook, you can then re-hide the account.

Method 2:

Use the legacyExchangeDN attribute of the account to add the mailbox.
Pre-Exchange 2000, you did this by adding the actual Distinguished Name
of the mailbox, which could be obtained by opening the Exchange Admin
program in raw mode and obtaining the DN of the object. Details of
doing that are documented in http://support.microsoft.com/?kbid=142781.

With Exchange 2000 and newer, this capability still exists, but instead
of using the DN, you use the legacyExchangeDN. Note that using the full
Distinguished Name of the object will not work for Exchange 2000 and
newer - it must be the legacyExchangeDN. Use the same procedure as
Method 1 (Tools, E-mail accounts, etc.) and when prompted for the
mailbox, enter the full legacyExchangeDN. You will notice that it is
then changed to the display name of the hidden object. This process
works the same when addressing a message to a hidden recipient. Simply
paste in the legacyExchangeDN, hit Ctrl-K, and the name will be resolved
to the display name of the hidden user.

How do you get the legacyExchangeDN value, you ask? Easy. Use ADSIEdit
(part of the Windows 2000/2003 support tools), or use your favorite LDAP
client (ldp.exe is either part of the support tools, or part of the
Resource Kit) and list the attributes of the hidden user.

Note that the above instructions assume that you are adding a hidden
mailbox as an "additional" mailbox, but the procedure should work the
same for setting up a new profile.

- posted by Ben Winzenz @ 1:05 PM 1 comments

 
My new toy - Imate Jasjar

Ok, so I've got a new toy. I previously owned a Dell Axim X5, but
unfortunately, didn't use it a whole lot. Why? To be honest, a
standalone PocketPC doesn't offer a ton of value to me. Sure, it was
intrigueing at first, and I used it for things like creating grocery
lists, and I installed some programs on it like an eBook reader, but it
wasn't something I used every day. It didn't have phone functionality
and it didn't have built-in wireless. One nice thing I did like was
that it had both a CompactFlash AND Secure Digital memory slot.

Anyway, back to my new device...

The Imate Jasjar is a Windows Mobile 5.0 device with a 62-key QWERTY
keyboard, and a 180-degree swivel screen. It also includes 2 cameras
(one for video conferencing) and is a fully functional phone. The size
is about as big as most other Pocket PC's, which means that if you will
be using it as your primary cell phone, you will want to have a
earpiece, likely a Bluetooth headset. Details about the Jasjar can be
found on Imate's website here:
http://www.imate.com/DETAILS_JASJAR.htm

First thoughts...
1. Needs a more robust voice-dialing package. Microsoft Voice Command
is supposed to do wonders - the built in Voice dialing package just
doesn't have enough features. Having a Bluetooth headset that supports
CallerID would be great here too, but I'm not about to shell out for one
yet.
2. I LOVE the swivel screen. I almost think of this as a mini-tablet
PC. Handwriting recognition works very well (I tried writing very
sloppily and it still correctly translated it to text).
3. The speed seems slow, even compared to my old PPC (300Mhz). This
has more memory (Flash and RAM), and also has a 520Mhz processor.
Hopefully this will change with ROM updates that optimize some more
things.
4. Syncing with Exchange via ActiveSync leaves a little bit to be
desired. I can't wait for the Messaging and Security Feature Pack
(MSFP) - it should improve things quite a bit. Notably, there will be
no more SMS messages to notify the device that there is new mail. I've
found so far that another area where Exchange ActiveSync isn't quite
like BES is that Exchange only notifies you when there are new messages
in your Inbox. If you are like me, and have server-side rules to move
messages into other folders, you will not be notified when messages get
dropped in those folders. I don't know of a way to configure ActiveSync
to notify you if messages arrive in folders other than your inbox.
5. The battery life can be pretty bad. Coming from my Axim, where the
battery would last the better part of a week, my Jasjar lasts about 2
maybe 3 days if I don't use Wireless. If I do, I pretty much have to
recharge it on a daily basis. I'm sure that the extended life batteries
will be gobbled up once they come out.
6. This is a quad-band phone, but coverage in the US will likely be
spotty. It only supports the 1800Mhz US GSM band, which both Cingular
and T-Mobile use, but Cingular also uses the 850Mhz band. I've been
using this with T-Mobile, and haven't had any problems with coverage
thus far. Phone quality seems fine. The packaged earpiece is good. I
should note that the Jasjar uses a standard size 3.5mm plug instead of
the mini one that most cell phones use.
7. AWESOME screen. It has a VGA screen (640x480 resolution) that is
stunning. I had a few days with both this and my old Axim, and there is
just no comparison. Even using the Terminal Services client is now
usable.
8. The keyboard is very usable. I've tried typing e-mails on
Blackberry devices - they are horrible (for me). The size of the keys
on Blackberries is too small for me to thumb type (which is what you
need to do). The keys on this are just the right size. If you want,
you can even set it on your desk and type with a few fingers - this also
works well. There is also a backlight that lights up the keys in a red
glow in low light situations. My only complaint about the keyboard (a
weak one at that), is that there is only one shift key and Function key
(on the left side of the keyboard), so if I have to type a symbol, I
have to use my left hand to hit the shift or Fn key, even though there
are some keys with symbols on the left side of the keyboard.

Do you use a Windows Mobile device? If so, which one do you use? Does
it have phone capability? Are you able to use it as your only mobile
device?

- posted by Ben Winzenz @ 8:29 AM 0 comments