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
| Thu Oct 28 19:41:16 2010 michael [...] bizsystems.com
fixed in release 4.035
Actually ... maybe not fixed ... investigating
Mark
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
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 workaround
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
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 for the
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
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: u...@example.com
I've been playing with a rule to identify this particular pattern (and
score in metas):
header LR_OBSC_RECIPS To =~
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
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
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
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: u...@example.com
Just FYI, I have a rule for that in my sandbox. It hit six messages in the
current nightly
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,
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 -
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
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
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
17 matches
Mail list logo
