On Fri, Oct 29, 2010 at 10:02:56PM -0400, dar...@chaosreigns.com wrote:
> I see there's a RDNS_NONE rule for when the sending IP address has no DNS
> PTR (reverse DNS) record. But no rule for when that PTR record doesn't
> have a matching A (forward DNS) record that matches the sending IP?
>
> Is
On 10/30, Michael Parker wrote:
> > I'd like to see spamassassin only run network tests when they might
> > affect the outcome.
>
> Why?
To reduce the network load on my server which is one of the hosts of the
DNSWL.org list?
> Assuming a reasonably fast connection network checks are basically f
On 10/30, m...@khonji.org wrote:
> I misread your email then, my bad.
>
> As far as I understand it now, is that you are getting the hostname by
> reverse DNS lookup against the connecting SMTP peer (that is sending a mail).
>
> Then you use that FQDN to for a DNS A RR query. And you expect this
On Oct 29, 2010, at 8:42 PM, dar...@chaosreigns.com wrote:
> I'd like to see spamassassin only run network tests when they might
> affect the outcome.
Why?
Assuming a reasonably fast connection network checks are basically free.
They are kicked off at the start of a scan and the results are co
I misread your email then, my bad.
As far as I understand it now, is that you are getting the hostname by reverse
DNS lookup against the connecting SMTP peer (that is sending a mail).
Then you use that FQDN to for a DNS A RR query. And you expect this IP address
to match to match against the SM
I never said anything about the domain matching the MAIL FROM. Or anything
else. Just that the sending IP have a PTR record which matches an A record
which matches the sending IP. Any domain. And, of course, the test would
have false positives, as do most others.
But as I said, I already blo
How do you expect this to handle cases when a single IP address (i.e single
MTA) is responsible for sending emails for multiple domains. The domain name
match won't happen for all.
That's why we have SPF, SenderID (MS didn't want to feel left out, and DKIM
(RFC standard).
As far as reverse loo
I see there's a RDNS_NONE rule for when the sending IP address has no DNS
PTR (reverse DNS) record. But no rule for when that PTR record doesn't
have a matching A (forward DNS) record that matches the sending IP?
For example, if you get an email from me, and look up the IP:
64.71.152.40 -> cha
I'd like to see spamassassin only run network tests when they might
affect the outcome.
For example, if you run all non-network tests, and at that point an email's
score qualifies as spam, and then you run all the non-spam network tests
(hitting whitelists), and it still qualifies as spam, there's
On Fri, 29 Oct 2010, NFN Smith wrote:
I'm seeing some amount traffic with obfuscated content in To: lines,
where the display name is shown as a angled bracket. For example:
To: "<"
Just FYI, I have a rule for that in my sandbox. It hit six messages in the
current nightly masscheck spam c
On 29/10/2010 4:06 PM, NFN Smith wrote:
Lawrence @ Rogers wrote:
On 29/10/2010 3:32 PM, NFN Smith wrote:
header LR_OBSC_RECIPS To =~ /\"\<\"/
Is this rule being used standalone, or as part of a meta rule? Do you
have a score declared for it? If so, what is it?
Right now, I'm scor
Lawrence @ Rogers wrote:
On 29/10/2010 3:32 PM, NFN Smith wrote:
header LR_OBSC_RECIPS To =~ /\"\<\"/
Is this rule being used standalone, or as part of a meta rule? Do you
have a score declared for it? If so, what is it?
Right now, I'm scoring at 1.25 points. Thus, it's not a hid
On 29/10/2010 3:32 PM, NFN Smith wrote:
header LR_OBSC_RECIPS To =~ /\"\<\"/
Is this rule being used standalone, or as part of a meta rule? Do you
have a score declared for it? If so, what is it?
Does spamassassin --lint report any errors at the end of its output?
Cheers,
Lawrence
I'm seeing some amount traffic with obfuscated content in To: lines,
where the display name is shown as a angled bracket. For example:
To: "<"
I've been playing with a rule to identify this particular pattern (and
score in metas):
header LR_OBSC_RECIPS To =~ /\"\<\"/
When r
On 10/29/10 12:11 PM, Mark Martinec wrote:
Sure, go ahead, can't hurt. The patch is now in the SA trunk.
Is it worth opening a ticket and putting it into the 3.3 branch too?
Mark
looks like Freebsd ports has an older version, so it should be ok.
pkg_info | grep NetAddr
p5-NetAddr-IP-4.02.8
Giampaolo,
> > still incorrect:
> > $ perl -le 'use NetAddr::IP; print NetAddr::IP->new6("127/8")'
> > 0:0:0:0:0:0:7F00:0/8
>
> This seems way too ambiguos to me, isn't?
No, it isn't ambiguous, it is a perfectly valid syntax for an IPv4
network, although nowadays somewhat deprecated in favour
Patch for SpamAssassin Ports, rpm's and yum? or would it hurt to do this
to 3.3.2 before it gets released?
On 10/29/10 11:01 AM, Mark Martinec wrote:
A workaround for SpamAssassin is to avoid shorthand IPv4 network
specifications, both in a config file (trusted/internal networks,
if any), as w
> still incorrect:
> $ perl -le 'use NetAddr::IP; print NetAddr::IP->new6("127/8")'
> 0:0:0:0:0:0:7F00:0/8
This seems way too ambiguos to me, isn't? How could the NetAddr::IP module
get you're instantiating an IPv6 net address, after all. That seems to me a
valid IPv6 syntax, too...
> A work
On Friday 29 October 2010 16:35:31 Mark Martinec wrote:
> > | Thu Oct 28 19:41:16 2010 michael [...] bizsystems.com
> >
> > fixed in release 4.035
>
> Actually ... maybe not fixed ... investigating
NetAddr::IP 4.035:
correct, this case is now fixed:
$ perl -le 'use NetAddr::IP; print NetAddr
> | Thu Oct 28 19:41:16 2010 michael [...] bizsystems.com
> fixed in release 4.035
Actually ... maybe not fixed ... investigating
Mark
On Thursday 28 October 2010 17:34:28 Giampaolo Tomassoni wrote:
> I'm too late: Steve Huff already did it...
> See: https://rt.cpan.org/Public/Bug/Display.html?id=62521 .
Perfect. Thank you guys.
| Thu Oct 28 19:41:16 2010 michael [...] bizsystems.com
fixed in release 4.035
Mark
21 matches
Mail list logo
