[vox-tech] OT: one of the most pernicious spams i've ever seen.

[Micah J. Cowan]

On Thu, Sep 25, 2003 at 10:39:09PM -0700, Ken Bloom wrote:
> 
> On 2003.09.25 21:53, Rob Rogers wrote:
> > On Thu, Sep 25, 2003 at 20:00:51PM -0700, Mitch Patenaude wrote:
> > Sorry. I was thinking back to my earlier email where I was discussing
> > encoding a domain name to look innocuous. Here was my example:
> > 
> > http://www.citibank.com%2e%61%33%6b%73%64%2e%50%69%53%65%4d%2e%4e%65%54
> > 
> > which unencoded becomes http://www.citibank.com.a3ksd.PiSeM.NeT
> > (using the actual base domain from the original email)
> > 
> >  This much your browser would have to decode to do a DNS lookup, and   
> > I've  never seen a browser show it encoded. Whether or not it sends  
> > it  encoded  in the referer, I can't speak with any authority, but I  
> > highly doubt  it  does. As for anything after the servername and/or  
> > port #, I realize  it  does send that encoded. I appologize for not  
> > making myself clear at  first.
> 
> The browser doesn't decode this anywhere. If you try to connect to  
> http://%61mazon.com/ that's exactly what it will try to look up the IP  
> address for so that it can connect. Not "amazon.com". %encoding is just  
> a clever hack to send data to a server, not an "official" alternate way  
> of specifying the location of a document.

Not sure what you mean by "not official" (look it up in any
URL/URI-standard you choose, and especially in RFC 2616 for how it
relates to HTTP). However, escape characters are not allowed within
the hostname portion, so you're right that it will not be decoded
(they shouldn't be looked up, though, either: % is not a syntactically
valid character in the host portion); and also that, for the most
part, it's the server that does URL decoding. However, relative URIs
and username/password combos (FWICT, *not* official... per RFCs 2616
and 2396) would have to be decoded by the user agent before being sent
on to the server.

-Micah