Yea itís quite easy to forge a link. Its seems to be kind of ok in zimbra's case since it goes out to alexa for a thumbnail instead of the site its self, but still if a user was to click on the link it would open the hidden URL. There is no real good way implemented to show the user, like dijichi2 said in the status bar the actual URL, they're about to click on a nasty URL. Something I also think should be taken care of soon. If thereís not a bugzilla report on it. I'll make one soon.
On the other subject of this thread of what its doing when the client does a mouse over a link. Here a capture of the HTTP packet when the client does HTTP get for the thumbnail from alexa. 192.168.10.2 is the client with the web UI open. 184.108.40.206 is pthumbnails.alexa.com, decem.unilogiclabs.com is my zimbra server. http://www.msn.com is the link that thumbnail is for.
So it does id your server to alexa but thatís all. My question is why is it necessary to id the zimba server to the alexa server. The link works fine without the id, ie.
Internet Protocol, Src: 192.168.10.2 (192.168.10.2), Dst: 220.127.116.11 (18.104.22.168)
Transmission Control Protocol, Src Port: 3731 (3731), Dst Port: http (80)
Hypertext Transfer Protocol
GET /image_server.cgi?id=decem.unilogiclabs.com&url=http://www.msn.com/ HTTP/1.1\r\n
Request Method: GET
Request URI: /image_server.cgi?id=decem.unilogiclabs.com&url=http://www.msn.com/
Request Version: HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060308 Firefox/126.96.36.199\r\n
I'd personally rather not have alexa knowing the hostname of my server every time a client views a thumbnail. Also to note once a client views a thumbnail, zimbra seems to cache it. Hope that helps.
Edit: Added Bug 7313 for the mouse hover URL in status bar problem, http://bugzilla.zimbra.com/show_bug.cgi?id=7313