I'll take a stab at what that first SRC IMG line does, because I used to have a cookie-leak demo on my site that used the same technique.
It's generating an on-the-fly link back to www.yourdomain.com for a 1 x 1 "web bug" image, which will not show up on the screen because it's probably transparent anyway. The purpose of this is to get the extra PATH_INFO into the link, so that www.yourdomain.com can collect it. Everything after the actual CGI program that generates the 1 x 1 in this path statement ends up in the environment variable PATH_INFO, which is accessible to that CGI program. The escape is to hex-encode any unusual characters so that they won't screw up the data transfer; these will get decoded later. ( for example, %3A = :, %2F = / )
It appears that this extra info in the path consists of the HTTP_REFERER seen by domain1.com.
Thus, www.yourdomain.com gets this information:
1) A log of exactly when this code was executed the remote domain1.com
2) Where the link was, that was clicked, that caused this code to be executed at that time on the remote domain1.com
I got bored so I didn't look at it past that first SRC IMG statement, but you probably have enough info now to figure out the rest of it.
And at the point of connection between domain1.com and www.yourdomain.com, the latter can plant or read a cookie on domain1.com.