[SpamCop-List] Re: New link obfuscation?
nobody at spamcop.net
Sun Mar 21 10:19:12 EST 2004
"Philippe Verdy" <verdy_p at wanadoo.fr> schrieb im Newsbeitrag
news:c3k8r1$auu$1 at news.spamcop.net...
> > http://email@example.com/stl/more2.php?m=x
> > That puzzles me - as far as I know everything before the @ should be
> > removed, and we get:
> > http://upgradingyourbrowser.com/stl/more2.php?m=x
> You're right here: anything that appears after the "http:" URI scheme and
> the immediately following "//" absolute location specifier, and before the
> first @ of the line is part of the user authentication string. When a "@"
> present in a HTTP url, all what appears before the first "@" of the URL
> never be interpreted as a host name. Note also that a user identity string
> may contain a "@" character or a ":" if they are URL-encoded with %40 and
> %38 respectively. The "@" is then syntaxic and must be parsed before
> URL-decoding any part of an URL.
Well, that is not correct, at least in respect to RFC 1738 (URL). It is
ip-schemepart = "//" login [ "/" urlpath ]
the definition of login does not allow any "/" (escaped characters always
excluded), i.a.w. the "/" is the sign that the login part (or host in this
case) is finished. Anything after the "/" is part of the path. So the URL
above resolves to hostingprod.com and there to "@upgrading..."
And to be even more exact, RFC 1738 actually does not allow the
user:password@ for http URLs. I am still wondering where this is actually
introduced. The @ syntax for the login information applies basically only to
the ftp and telnet schemes. It is natural to use to also for http, but it is
still not compliant to RFC 1738 (or RFC 2616 HTTP/1.1)
Your shown example for ftp is in any respect correct and not contradictory
to anything said above. And my IE 6 does it correctly: it shows
hostingprod.com. The problem is that hostingprod.com brings up a page that
these strange "effects" Ellen reported...
More information about the SpamCop-List