all those nice ups.com rules, tests and signatures?
the EXACT same file that was in a ups.com virus? is now being sent
'from' dhl.com
(come on ups/dhl.. I know SPF is broken, but in this case it would sure
help is decide if the sending ip is authorized to send on your behalf)
with some
On 03/31/2011 08:59 AM, Michael Scheidell wrote:
all those nice ups.com rules, tests and signatures?
the EXACT same file that was in a ups.com virus? is now being sent
'from' dhl.com (come on ups/dhl.. I know SPF is broken, but in this
case it would sure help is decide if the sending ip is
On 31/03/2011 1:29 PM, Michael Scheidell wrote:
'from' dhl.com
(come on ups/dhl.. I know SPF is broken, but in this case it would
sure help is decide if the sending ip is authorized to send on your
behalf)
with some pretty weird received lines: is this 'ipv8'?
Doubtful. IPv8 is still very
it's IPv4.5
-lee
On 3/31/2011 1:47 PM, Lawrence @ Rogers wrote:
On 31/03/2011 1:29 PM, Michael Scheidell wrote:
'from' dhl.com
(come on ups/dhl.. I know SPF is broken, but in this case it would
sure help is decide if the sending ip is authorized to send on your
behalf)
with some pretty
On 3/31/11 1:46 PM, Adam Katz wrote:
On 03/31/2011 08:59 AM, Michael Scheidell wrote:
What rules? Running `grep -Pri '\b\w?ups' rules*` ('\w?' allows for
matching '\bups') hits only one related rule, DOS_FAKE_UPS_TRACK_NUM,
which is still in testing (and keys on the word 'UPS' in the subject,
On 31/03/11 19:07, Michael Scheidell wrote:
On 3/31/11 1:46 PM, Adam Katz wrote:
On 03/31/2011 08:59 AM, Michael Scheidell wrote:
What rules? Running `grep -Pri '\b\w?ups' rules*` ('\w?' allows for
matching '\bups') hits only one related rule, DOS_FAKE_UPS_TRACK_NUM,
which is still in testing
On 3/31/11 2:34 PM, Ned Slider wrote:
I'd go a step further and say no way you should be accepting
executables at the smtp level, so no reason to be passing them to SA
for scanning in the first place. These should be rejected or
quarantined elsewhere in the mail chain.
sure, in my home
On 3/31/2011 1:34 PM, Ned Slider wrote:
I'd go a step further and say no way you should be accepting
executables at the smtp level, so no reason to be passing them to SA
for scanning in the first place. These should be rejected or
quarantined elsewhere in the mail chain.
Agreed. One of my
On Thu, 31 Mar 2011, Michael Scheidell wrote:
received:from smtp1.txfxczpw.net ([11169.98.12888.1258]) by relay.cxjrc.com
with SMTP; Thu, 31 Mar 2011 09:09:04 -0600
...aren't there any rules for invalid IPs like that? There don't appear to
be any that validate IPv4 limits. {boggle}
Were
On 3/31/11 3:27 PM, John Hardin wrote:
On Thu, 31 Mar 2011, Michael Scheidell wrote:
received:from smtp1.txfxczpw.net ([11169.98.12888.1258]) by
relay.cxjrc.com with SMTP; Thu, 31 Mar 2011 09:09:04 -0600
...aren't there any rules for invalid IPs like that? There don't
appear to be any that
On 3/31/11 3:27 PM, John Hardin wrote:
On Thu, 31 Mar 2011, Michael Scheidell wrote:
received:from smtp1.txfxczpw.net ([11169.98.12888.1258]) by
relay.cxjrc.com with SMTP; Thu, 31 Mar 2011 09:09:04 -0600
...aren't there any rules for invalid IPs like that? There don't
appear to be any that
On 3/31/11 3:27 PM, John Hardin wrote:
On Thu, 31 Mar 2011, Michael Scheidell wrote:
received:from smtp1.txfxczpw.net ([11169.98.12888.1258]) by
relay.cxjrc.com with SMTP; Thu, 31 Mar 2011 09:09:04 -0600
egrep '^Received: from .* \(\[.*\.?[0-9]{4}+\.?\]\) by' NqamNZvwyRnh.eml
would need SA
From: Michael Scheidell michael.scheid...@secnap.com
using amavisd-new, we can set up policies, per user, and per domain if
needed to match the end users needs.
Via Amavis one can even ban executable attachments. With few work, one can
develop a system which notifies users that such a
On 3/31/11 6:15 PM, Giampaolo Tomassoni wrote:
Via Amavis one can even ban executable attachments. With few work,
one can develop a system which notifies users that such a message had
been received and blocked, along with a link to an unlock web page.
There users could see the message source,
14 matches
Mail list logo
