Mailing-List: contact users-help@spamassassin.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: 11 Mar 2012 08:51:47 -0000
Subject: Re: Better phish detection  
To: users@spamassassin.apache.org
From: hamann.w@t-online.de
Message-Id: <wolfgang-1120311095147.A0416300@amadeus3.local>
Content-type: text/plain; charset=iso-8859-1
In-Reply-To: <alpine.OSX.1.10.1203101431560.67114@Dave-silver-mini.local> 


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 512
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
javascript

>> [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 from
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 average
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 or
Outlook. So the incentive is: have better workflow for the majority of messages, in exchange for
a need to hit "view in browser" for some messages