You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Richard Leroy <rl...@avantages.com> on 2005/11/01 16:50:03 UTC

Re: Integrity checks in URLs for blocking phishers as anti-phishing prevention

Kelson wrote:
> Matthew.van.Eerde@hbinc.com wrote:
>>> <A HREF="http://hacker.com">http://legit-bank.com</a>
>>>
>>> On top of my mind, I never saw a situation like this in real life,
>>> except in phish emails.
>>
>> I see this all the time in promotional emails (spam, not phish) to track
> > clickthrough.
>
> I see it on legit mail too, including a couple of newsletters and, in 
> one case, an "item not won" notice from eBay.  Yes, it was legit.  
> This has caused a number of legit messages to trip Thunderbird's new 
> phishing filter.
>
> It's a poor practice, and in the case of eBay they seem to do the 
> right thing on their other notices (either matching the URL to the 
> text or using descriptive link text instead of a hostname), but sad to 
> say there *is* legit mail that uses redirectors in this fashion.
>
> So it's worth scoring, but not safe to score too highly or use as 
> rejection criteria unless you whitelist the legit senders (or convince 
> them to change their ways).
>
My point is that I want to make this check an "integrity check".  If you 
choose to display a URL, then it must match the real URL, nothing else.  
Too bad if it is classified as a false-positive.  The benefits in 
helping stop "phishers" are way larger than the advantage of displaying 
a different URL than the advertised one.

Also, I will feel better if a email is classified as a false-positive if 
it has hits on this rule than any other rule, because I can say that the 
sender is in part related to classification error.

--
Richard Leroy
rleroy@avantages.com

Re: Integrity checks in URLs for blocking phishers as anti-phishing prevention

Posted by mouss <us...@free.fr>.
Richard Leroy a écrit :

> The situation I am talking about is when the text IS a URL.
>
> I don't want to block this: <a href="http://www.hacker.com">CLICK HERE 
> !!!</a>.  I understand that this situation happens frequently.
>
> I want to bloc URLs when the text has http:// before it, like in this 
> example: <a href="http://www.hacker.com">http://www.real-bank.com</a>
>
I understand, but as soon as you have this in SARE, spammers will use
    <a href="http://www.hacker.com">www.real-bank.com</a>
would you also catch www.*? then, they will add some text or html tags. 
If it's step by step, we won't win the race...


Re: Integrity checks in URLs for blocking phishers as anti-phishing prevention

Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Nov 01, 2005 at 12:27:34PM -0500, Richard Leroy wrote:
> I don't want to block this: <a href="http://www.hacker.com">CLICK HERE 
> !!!</a>.  I understand that this situation happens frequently.
> 
> I want to bloc URLs when the text has http:// before it, like in this 
> example: <a href="http://www.hacker.com">http://www.real-bank.com</a>

Doesn't work, the hit rate is horrible.  Looked into this several months ago
when doing up some anti-phishing rules.

-- 
Randomly Generated Tagline:
"The only way you'll get me to talk is through slow painful torture, and I
 don't think you've got the grapes."     - Stewie on Family Guy

Re: Integrity checks in URLs for blocking phishers as anti-phishing prevention

Posted by Richard Leroy <rl...@avantages.com>.
mouss wrote:
> Richard Leroy a écrit :
>
>> My point is that I want to make this check an "integrity check".  If 
>> you choose to display a URL, then it must match the real URL, nothing 
>> else.  Too bad if it is classified as a false-positive.  The benefits 
>> in helping stop "phishers" are way larger than the advantage of 
>> displaying a different URL than the advertised one.
>
> but then you are adding requirements to what a display text is. The 
> following is fully legitimate.
>    a url is somethink like <a href=http://en.wikipedia.org/Url> 
> example.com </a>
>
> and what to do if it's not a url? something like
> <a href=http://www.something.example> the site of foo.example </a>
> is legitimate, but something like
> <a href=http://www.hacker.example> visit www.bank.com </a>
> is not.
>
> Also, as already said, some legitimate opt-in newsletters do use this 
> trick to implement tracking. you can consider this bad practice, but 
> not everybody can afford to block legitimate opt-in 
> newsletters/services/...
>
>>
>> Also, I will feel better if a email is classified as a false-positive 
>> if it has hits on this rule than any other rule, because I can say 
>> that the sender is in part related to classification error.
>
> sure, but those of us concerned with FPs prefer to find other ways to 
> detect spam.
>
The situation I am talking about is when the text IS a URL.

I don't want to block this: <a href="http://www.hacker.com">CLICK HERE 
!!!</a>.  I understand that this situation happens frequently.

I want to bloc URLs when the text has http:// before it, like in this 
example: <a href="http://www.hacker.com">http://www.real-bank.com</a>

Thanks for replying,

--
Richard Leroy
rleroy@avantages.com

Re: Integrity checks in URLs for blocking phishers as anti-phishing prevention

Posted by mouss <us...@free.fr>.
Richard Leroy a écrit :

> My point is that I want to make this check an "integrity check".  If 
> you choose to display a URL, then it must match the real URL, nothing 
> else.  Too bad if it is classified as a false-positive.  The benefits 
> in helping stop "phishers" are way larger than the advantage of 
> displaying a different URL than the advertised one.

but then you are adding requirements to what a display text is. The 
following is fully legitimate.
    a url is somethink like <a href=http://en.wikipedia.org/Url> 
example.com </a>

and what to do if it's not a url? something like
<a href=http://www.something.example> the site of foo.example </a>
is legitimate, but something like
<a href=http://www.hacker.example> visit www.bank.com </a>
is not.

Also, as already said, some legitimate opt-in newsletters do use this 
trick to implement tracking. you can consider this bad practice, but not 
everybody can afford to block legitimate opt-in newsletters/services/...

>
> Also, I will feel better if a email is classified as a false-positive 
> if it has hits on this rule than any other rule, because I can say 
> that the sender is in part related to classification error.

sure, but those of us concerned with FPs prefer to find other ways to 
detect spam.