On 2010-03-01 15:39, John Hardin wrote:
[ About ExtractText.pm]
Jonas, what's the current status of that plugin? It looks pretty stable
to me.
It works fine here. Don't know how it works for others. I haven't tested
it with 3.3 yet.
And, can it extract from basic text attachments? I
On Sun, 28 Feb 2010, LuKreme wrote:
SPF!
runs; ducking, shucking, and weaving
You're a brave person. ;)
It's easier to understand the challenge Dave faces, if we look at
some actual From headers.
In my stream, these started in early November of last year, so I
just checked a few months
On Tue, 2 Mar 2010, Chip M. wrote:
Since these started, they've had 19 of these phish:
1 Bank of Americasupp...@boa.com
1 PayPaIupd...@paypai.com
1 Paypal Inc.cust_s...@paypalsecurity.com
1 serv...@irs.govserv...@irs.gov
1 serv...@paypal.comc
1
On Tue, 2 Mar 2010, John Hardin wrote:
Would you be willing to test this and see how well it does in practice?
{grumble} reply-to {grumble}
Sorry for spamming the list with this, it was meant just for Chip.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
On Mon, 1 Mar 2010, Benny Pedersen wrote:
On man 01 mar 2010 02:37:37 CET, John Hardin wrote
I've suggested this before, but the current position appears to be if the
MUA doesn't display it automatically, why should we scan it?
same goes for just enter this url when the sender was tired of
On Sun, 28 Feb 2010, LuKreme wrote:
Your best bet is to check if mail claiming to be from paypal is, in fact,
from paypal.
Actually, I think his problem is that the reference to paypal has been
buried in an attachment, described as 'type' of 'octet/binary' so that SA
won't think it is text
On Sun, 28 Feb 2010, LuKreme wrote:
On 28-Feb-10 17:25, David B Funk wrote:
I'm seeing a spate of PayPal/bank phishes that use an html attachment
(base-64 encoded) as the vehicle for the payload.
SPF!
runs; ducking, shucking, and weaving
Actually I'm happy to utilize SPF when I can. But
On Mon, 1 Mar 2010, Charles Gregory wrote:
On Sun, 28 Feb 2010, LuKreme wrote:
Your best bet is to check if mail claiming to be from paypal is, in fact,
from paypal.
Actually, I think his problem is that the reference to paypal has been
buried in an attachment, described as 'type' of
On Mon, 1 Mar 2010, David B Funk wrote:
Looks like he may have to use a 'full' test to look for the references to
paypal
Been there, done that, doesn't work.
AFAIK SA ignores 'octet/binary' attachments for the rule engine. None of
the rules that I tried (uri, body, full, rawbody) saw
On Mon, 1 Mar 2010, Charles Gregory wrote:
On Mon, 1 Mar 2010, David B Funk wrote:
Looks like he may have to use a 'full' test to look for the references
to
paypal
Been there, done that, doesn't work.
AFAIK SA ignores 'octet/binary' attachments for the rule engine. None of
the
On 01-Mar-10 12:45, David B Funk wrote:
AFAIK SA ignores 'octet/binary' attachments for the rule engine. None of
the rules that I tried (uri, body, full, rawbody) saw anything that was
known to be in one of those attachments.
So there was no paypal info (spoofed) in the headers at all?
But
On Sun, 28 Feb 2010, David B Funk wrote:
Is there any way to get SA to treat that attachment as text to feed to
the rule engine?
I've suggested this before, but the current position appears to be if the
MUA doesn't display it automatically, why should we scan it?
Justin, I would
On man 01 mar 2010 02:37:37 CET, John Hardin wrote
I've suggested this before, but the current position appears to be
if the MUA doesn't display it automatically, why should we scan it?
same goes for just enter this url when the sender was tired of doing
it right, fuzzyocr solved this
On 28-Feb-10 17:25, David B Funk wrote:
I'm seeing a spate of PayPal/bank phishes that use an html attachment
(base-64 encoded) as the vehicle for the payload.
SPF!
runs; ducking, shucking, and weaving
Is there any way to get SA to treat that attachment as text to feed to
the rule engine?
14 matches
Mail list logo
