On Monday, May 17, 2004, 4:10:51 PM, John Fawcett wrote:
From: "jdow"
From: "John Hardin" johnh@aproposretail.com
On Sun, 2004-05-16 at 01:46, John Fawcett wrote:
In order to obtain the 302 code the browser sees 2 things are necessary:
- Add a / before the * (That is the correct format for
yahoo redirection) 2. Change the hTtP:\ to hTtP:// (The mixed case is not a problem)
I think fixing all backslashes to forward slashes in the URL before processing by SURBL would deal with both cases.
Are (unescaped or unencoded) backslashes even *valid* in URLs?
Um, who cares? If the email programs parse them the way the spammers want then we need to catch them parsed the way the spammers want. Of course we COULD simply dump emails containing illegitimate back slashes if nothing Microsoftish produces legitimate emails with backslashes. I do not want to bet on that.
{^_^}
In this case there is an additional consideration: SpamCopURI has logic to get the spammer domain out of a redirection url, by actually doing an http retrieval and reading the 302 response header. This retrieval fails if done on the url as written by the spammer. So the options are:
- use unescaped \ as a spam indicator
- mimic the broken browsers/email clients which are apparently rewriting
malformed urls by mapping \ to /, thus allowing SpamCopURI to successfully retrieve the spammer domain for testing against surbl.
I would vote for the latter: map \ to /
(Although treating \ used as a separator as a --clue indicator could also be useful, likewise using / for command line flags. ;-)
Jeff C.