I think he's trying to use PROPFIND to make his operation more efficient on MS servers with DAV available. I haven't used DAV before, but maybe he can get the properties of the image (size, type, date, author - all that stuff you see associated with MS-tool-created documents) using PROPFIND, and do it more efficiently than downloading each image individually and 'looking at it'.
If this "theory" holds up, what it means is that they don't want the image, they want information about the image, so my call would be that they're looking for copied copyrighted images.
There has to be a big payoff to this, otherwise using a MS-only method when half the world uses Apache would be a huge waste of time. So, I think they want to know something about the image without downloading the image itself, if possible. So, they try PROPFIND first.
OK, absolutely everything above is a guess based on what you posted. I hope it's a logical guess, though.
For info on PROPFIND, take a look at the link cited in the other thread, and if that doesn't help, maybe use the info learned there to ask in the MS-related forum.
OK, first, your server can't do PROPFIND or won't allow it now. So to fix the real problem (image download and associated bandwidth) regardless of the requesting IP, you could look for that blank referer and blank user agent, but NOT a HEAD request. Maybe restrict the blocking to image files only at first. That will block some bad guys, but still let AOL's custom cache implementation work OK. AOL's cache does a HEAD request with blank referer and blank user-agent instead of a cGET with IF-MODIFIED-SINCE and the time they last cached the page -- they just gotta be different, I guess. Maybe it's an HTTP-version thing.