Re[2]: Phishing attempt wasn't blocked by SpamAssassin
Hello Wolfgang, Monday, December 6, 2004, 7:39:09 AM, you wrote: LW That's because such a rule won't work. All manner of real mail ends up LW sending things that have a real link address different from the one shown in LW the link. Often it is a very minor difference, like https vs http, but LW sometimes there are no points of reality at all between them. This shows up LW a lot in stuff generated from databases. WH if there is a visible url to a different server than the one in WH real url, I would not only want to tag that as possible spam, but WH rather have a nice red 20pt headline added to the mail: WARNING - WH DO NOT CLICK - THESE LINKS MIGHT BE FORGED As the current ninja maintaining the SARE URI rules file (though not the fraud or spoof files), I gladly invite you to develop such a rule. If you can offer us a rule that does what you want, and in our testing does not hit excessively on non-spam, we'll gladly include it in our SARE rules file, and will support your submission of that rule to the SA developers. At this point in time, I can't think of a good (efficient) way to do this that wouldn't also hit huge numbers of non-spam. Bob Menschel
Re: Re[2]: Phishing attempt wasn't blocked by SpamAssassin
On Mon, 2004-12-06 at 18:29, Robert Menschel wrote: Hello Wolfgang, Monday, December 6, 2004, 7:39:09 AM, you wrote: LW That's because such a rule won't work. All manner of real mail ends up LW sending things that have a real link address different from the one shown in LW the link. Often it is a very minor difference, like https vs http, but LW sometimes there are no points of reality at all between them. This shows up LW a lot in stuff generated from databases. WH if there is a visible url to a different server than the one in WH real url, I would not only want to tag that as possible spam, but WH rather have a nice red 20pt headline added to the mail: WARNING - WH DO NOT CLICK - THESE LINKS MIGHT BE FORGED As the current ninja maintaining the SARE URI rules file (though not the fraud or spoof files), I gladly invite you to develop such a rule. If you can offer us a rule that does what you want, and in our testing does not hit excessively on non-spam, we'll gladly include it in our SARE rules file, and will support your submission of that rule to the SA developers. At this point in time, I can't think of a good (efficient) way to do this that wouldn't also hit huge numbers of non-spam. Bob Menschel Just a note of information, for those looking to stop phishing attacks: the open source anti-virus program ClamAV has added signatures for several phishing emails. When this is used, they will be blocked before they ever hit SpamAssassin. Obviously, these are tailored for each specific message, so it's not a generic solution, but it can help. Currently, there are signatures for 18 different banking phish and two auction phish. http://www.clamav.net/ -Bill
Re: Re[2]: Phishing attempt wasn't blocked by SpamAssassin
On Mon, 2004-12-06 at 20:00, Kenneth Porter wrote: --On Monday, December 06, 2004 6:44 PM -0800 Bill Randle [EMAIL PROTECTED] wrote: Obviously, these are tailored for each specific message, so it's not a generic solution, but it can help. Currently, there are signatures for 18 different banking phish and two auction phish. Additionally, if you run SA and Clam from MIMEDefang, you can use the contributed Graphdefang package to serve graphs of your spam, viruses, and phish from your web server, and can see how many phishing attempts of each type were blocked. http://mimedefang.org/ Good point! I use amavisd-new with postfix and graphdefang for much the same thing. -Bill
Re: Re[2]: Phishing attempt wasn't blocked by SpamAssassin
Hello Bob, thanks for getting back on that. The problem with these mails - they may not be spam, they may not be fraud either, but they impose a different kind of threat by lowering recipients' thresholds on security. I have had that argument well, I read that mail, and nothing bad happened from users and dont want to have it again :) Maybe I should ask these kind of people to sign a paper that they will never ask me to disinfect there systems We have seen - banks that invite their custumers to click somewhere for their account statement - banks that suggest to go to the security tab in IE and drag the control to a lower setting as a response to cert wernings - microsoft generate cert warnings by putting a valid cert onto the wrong server and now we have legitimate mail with suspicious links It is all these things together that eventually make people tolerant to phish (well, I got this irritating broken cert thing every day from my bank as well - how should I know that their broken cert was different) I am also not sure whether anti spam is the proper place to deal with these messages - if they get enough score, recipients will just route them to the trash and later complain about the missing mail. I could even imagine to quarantine these mails and invite recipients to complain to the senders. In the case of the bank mentioned above, a bank smells like phish article in a local computer mag caused them to change the system Wolfgang Hamann Hello Wolfgang, Monday, December 6, 2004, 7:39:09 AM, you wrote: LW That's because such a rule won't work. All manner of real mail ends up LW sending things that have a real link address different from the one shown in LW the link. Often it is a very minor difference, like https vs http, but LW sometimes there are no points of reality at all between them. This shows up LW a lot in stuff generated from databases. WH if there is a visible url to a different server than the one in WH real url, I would not only want to tag that as possible spam, but WH rather have a nice red 20pt headline added to the mail: WARNING - WH DO NOT CLICK - THESE LINKS MIGHT BE FORGED As the current ninja maintaining the SARE URI rules file (though not the fraud or spoof files), I gladly invite you to develop such a rule. If you can offer us a rule that does what you want, and in our testing does not hit excessively on non-spam, we'll gladly include it in our SARE rules file, and will support your submission of that rule to the SA developers. At this point in time, I can't think of a good (efficient) way to do this that wouldn't also hit huge numbers of non-spam. Bob Menschel
Re: Phishing attempt wasn't blocked by SpamAssassin
On Monday, December 6, 2004, 4:02:59 AM, Eugene Morozov wrote: Hello! Our customer received email which contained invitation to confirm personal information at the online bank. Link was hidden using following trick: A href=http://www.designlaboratory.jp/board/hg.html;https://www.ebank.hsbc.com.hk/servlet/onlinehsbc.jsp/A It was a big surprise for me that there're no rules in the stock SA 3.0.1 installation to catch such forged links. I was also to unable to find such a rule on Rules Emporium. Eugene In addition to the other suggestions, I'd recommend reporting the phish to: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Doing so will help get some of the destation URIs into ph.surbl.org, though in this particular case I'm not sure that we should list designlaboratory.jp since this could be a Joe Job or hijacked message board. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Phishing attempt wasn't blocked by SpamAssassin
Hello! Our customer received email which contained invitation to confirm personal information at the online bank. Link was hidden using following trick: A href=http://www.designlaboratory.jp/board/hg.html;https://www.ebank.hsbc.com.hk/servlet/onlinehsbc.jsp/A It was a big surprise for me that there're no rules in the stock SA 3.0.1 installation to catch such forged links. I was also to unable to find such a rule on Rules Emporium. Eugene
Re: Phishing attempt wasn't blocked by SpamAssassin
Our customer received email which contained invitation to confirm personal information at the online bank. Link was hidden using following trick: A href=http://www.designlaboratory.jp/board/hg.html;https://www.ebank.hsbc.c om.hk/servlet/onlinehsbc.jsp/A It was a big surprise for me that there're no rules in the stock SA 3.0.1 installation to catch such forged links. I was also to unable to find such a rule on Rules Emporium. That's because such a rule won't work. All manner of real mail ends up sending things that have a real link address different from the one shown in the link. Often it is a very minor difference, like https vs http, but sometimes there are no points of reality at all between them. This shows up a lot in stuff generated from databases. I believe we (SARE) do have a rule that checks for a dotquad link and a link name that looks like it might be a bank. However, it is fairly specific to the more common bank scams, and won't catch the particular case you found. Loren
Re: Phishing attempt wasn't blocked by SpamAssassin
That's because such a rule won't work. All manner of real mail ends up sending things that have a real link address different from the one shown in the link. Often it is a very minor difference, like https vs http, but sometimes there are no points of reality at all between them. This shows up a lot in stuff generated from databases. Well, if there is a visible url to a different server than the one in real url, I would not only want to tag that as possible spam, but rather have a nice red 20pt headline added to the mail: WARNING - DO NOT CLICK - THESE LINKS MIGHT BE FORGED Of course, if the visible url says http://someshopping.com/camera/buy_canon and the real link is http://someshopping.com/cgi-bin/buy.cgi?prod=1381 AND the displayed url works too, no problem. The widespread use of a markup tool like this might even help to teach mail senders that this kind of mail is not wanted. To put it in other words: if phishing scam looks like ordinary new products from my favourite bookstore, and produce the same kind of there is something wrong with the certificate popup as my real bank does, it is not only the phishers to blame Just my 2c Wolfgang Hamann
