spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Better phish detection
Date Sun, 11 Mar 2012 08:51:47 GMT

Dave Funk wrote:

>> As an admin on a site that regularly gets hit with phish attacks, I can 
>> answer that. The forms are most often a web-page, which are:
>> 1) forms hosted on Google-Docs or legit servey sites.[0]
>> 2) sites hidden behind URL-shorteners
would you want to submit details to a site with a redirected url?
Probably SA is not the right tool here, because it would have to mark detected mail as "caution"

>> 3) forms hidden in pages hosted on compromised legit sites.[1]
>> 4) forms attached to mail messages, the attachments obfuscated by being
>>     MIME-typed as application/octet-stream but the file names ending in ".htm"
>>     so SA won't try looking inside but mail-clients -will- automagically
>>     "just do the right thing"(tm) [2]
sounds like a potential improvement on any filter: try to identify attachments by their first
bytes rather than by filename or mime type

>> 5) URIs that are obfuscated by being buried inside javascript that
>>     dynamically generates them at message open time.[3]
If there was a "caution" rather than just "potential spam" mark, it should certainly mark

>> [3] Damn people who insist that HTML should be acceptable everwhere.
>>      I tried creating rules that blacklist email containing javascript
>>      but there's legit sites (purchase confirmations, reservation notices,
>>      etc) that insist on doing that crap.

My own way of life:
a) messages that do not list me in either To or Cc (that is most mailing lists) must come
whitelisted senders, otherwise they do not even make it to SA
b) I read mails on a text interface with a nice "read this one message in browser" pushbutton
c) the actual sending email address should not be completely obscured in the mail reader,
in favor of a display name

I have implemented b) at the company where I work. For more than 50 % of mails handled by
staff, the same pushbutton means "open in application".
When this project started a decade ago, I could not find a way to associate that particular
class of mails
(identified by sender, subject line, and mime-type) with an application in either Netscape
Outlook. So the incentive is: have better workflow for the majority of messages, in exchange
a need to hit "view in browser" for some messages

View raw message