Philipp, shouldn't remote pictures inserted into forum postings be cached by you locally, perhaps even resized/"normalized" first, if over a certain binary and/or physical space limit, to prevent things like this from happening?

http://blogoscoped.com/forum/131899.html#id132042
originally contained a topical screenshot of the app in question – now the WordPress blog it came from has been hacked
http://www.iphoneworld.ca/news/2008/05/26/fingerrun-for-iphone/

(You could still insert the url to original picture, but send out the cached stream. Else simply put the original url in the img-title tag?)

In addition, I'd suggest that BG picture tags get explicit width and height args, so that e.g. 300dpi-picts saved at 25% --and there are plenty of such out there on that webby thing of ours-- do not render later (without size tags) at their full pixel size.

I certainly see several problems with not caching pictures, as you describe. Though there's also some issues with caching pics, like copyright... copying the picture to this server, even if I would put it in a special folder which I could disallow from robot-indexing, would create a copy that the original owner may subject to (not to suggest that hotlinking is free of such issues). Something to think about.

Perhaps you could cache a thumbnail version of the image and link to the original at the original domain, however this would add little benefit to viewers for the bandwidth and space that would be used over a long period of time. Wikipedia uses smaller versions of copyrighted material under Fai Use as it is a representation of the original, but not a complete copy, I believe.

Creating an automated thumbnail and then linking it to the big sized original version sounds interesting. Perhaps it would work best as some kind of nightly caching job as opposed to real-time download of the external pic, as that would create some delay during posting. I'll think about it.

As you said, hotlinking pictures is not without copyright/left problems of its own.... on the other hand it's fairly easy to prevent, if one absolutely must. It certainly was seen more of a problem when "interconnected tubes" weren't as wide as they are today.... I think the web has learned to accept not to fight such --effectively goodwill-- pictorial reuse.

That said, I really don't see caching as separate, extra-stage nightly cronjob (=too messy and too much of a Murphy Law waiting to happen).

Instead fetch and store the img at once, extract its pixel size; decide whether it is to be "normalized" (however you finally define it); write its FINAL width/ height args + title="url"; post the msg, AND THEN rewrite/ transform/ whatever the pic in situ, so that next view gets to see the cached copy, still with the same name. And don't make pictures into clickable hotlinks to their sources.... textual links underneath are more than enough (if needed at all). Added advantage of title arg set to original pict url, is that most visual browsers will be able to display it to viewer in context, too!