On Tue, 2014-06-10 at 21:22 -0400, Daniel Staal wrote:
> --As of June 11, 2014 2:45:25 AM +0200, Karsten Bräckelmann is alleged to
> have said:
> > Worse, enabling charset normalization completely breaks UTF-8 chars
> > in the regex. At least in my ad-hoc --cf command line testing.
>
> --
--As of June 11, 2014 2:45:25 AM +0200, Karsten Bräckelmann is alleged to
have said:
Worse, enabling charset normalization completely breaks UTF-8 chars
in the regex. At least in my ad-hoc --cf command line testing.
--As for the rest, it is mine.
This sounds like something where `use
On Tue, 2014-06-10 at 17:39 -0400, Alex wrote:
> On Tue, Jun 10, 2014 at 3:25 PM, Karsten Bräckelmann wrote:
> It's here where I'm starting to lose you:
Reading through your reply, I see we need to get to the basics first.
You are massively confusing different types of encoding and not fully
real
On 10. jun. 2014 23.33.37 CEST, s...@andreasschulze.de wrote:
>
>Kevin A. McGrail:
>
>> So theoretically to implement DMARC in SA, we should be ignoring
>> both SPF and ADSP.
>
>Kevin,
>
>DMARC work ontop of SFP and DKIM. A message get a DMARC pass if
>SPF *or* DKIM (or both) signal "Thumbs up"
>
On 10. jun. 2014 21.02.24 CEST, Jari Fredriksson wrote:
>jarif@whirlwind:~$ locate ClamAV.pm
>/usr/local/share/perl/5.10.1/File/Scan/ClamAV.pm
>/usr/local/share/perl/5.14.2/File/Scan/ClamAV.pm
>
>The file is there. Why can't it be found?
If it was gentoo i would run perl-cleaner all
As i see it
On Tue, 10 Jun 2014 23:33:37 +0200
s...@andreasschulze.de wrote:
>
> Kevin A. McGrail:
>
> > So theoretically to implement DMARC in SA, we should be ignoring
> > both SPF and ADSP.
>
> Kevin,
>
> DMARC work ontop of SFP and DKIM. A message get a DMARC pass if
> SPF *or* DKIM (or both) signal
Hi,
On Tue, Jun 10, 2014 at 3:25 PM, Karsten Bräckelmann
wrote:
>
> On Tue, 2014-06-10 at 13:53 -0400, Alex wrote:
> > I'm not very familiar with how to manage language encoding, and hoped
> > someone could help. Some time ago I wrote a rule that looks for
> > subjects that consist of a single wo
Kevin A. McGrail:
So theoretically to implement DMARC in SA, we should be ignoring
both SPF and ADSP.
Kevin,
DMARC work ontop of SFP and DKIM. A message get a DMARC pass if
SPF *or* DKIM (or both) signal "Thumbs up"
So ignoring SPF will produce wrong DMARC results at all.
Andreas
On Tue, 10 Jun 2014, Andrew Daviel wrote:
Per http://ahbl.org/content/changes-ahbl, AHBL is going away (still used in
spamassassin-3.3.1)
Meanwhile, AHBL is serving strange DNS responses, e.g.
(from wireshark)
1 0.00 142.90.100.186 -> 162.243.209.249 DNS 93 Standard query 0xc828
A zuz
On 06/10/2014 09:33 PM, Andrew Daviel wrote:
Per http://ahbl.org/content/changes-ahbl, AHBL is going away (still used
in spamassassin-3.3.1)
Meanwhile, AHBL is serving strange DNS responses, e.g.
(from wireshark)
1 0.00 142.90.100.186 -> 162.243.209.249 DNS 93 Standard query
0xc828 A
Per http://ahbl.org/content/changes-ahbl, AHBL is going away (still used
in spamassassin-3.3.1)
Meanwhile, AHBL is serving strange DNS responses, e.g.
(from wireshark)
1 0.00 142.90.100.186 -> 162.243.209.249 DNS 93 Standard query 0xc828
A zuz.rhsbl.ahbl.org
2 0.072481 162.243.2
On Tue, 2014-06-10 at 13:53 -0400, Alex wrote:
> I'm not very familiar with how to manage language encoding, and hoped
> someone could help. Some time ago I wrote a rule that looks for
> subjects that consist of a single word that's more than N characters.
> It works, but I'm learning that it's per
I need a hand with my perl. This has worked, but for some reason no more.
sa-learn says:
defined(@array) is deprecated at /etc/mail/spamassassin/EmailBL.pm line 321.
(Maybe you should just omit the defined()?)
plugin: failed to parse plugin /etc/mail/spamassassin/clamav.pm: Can't locate
Quoting Axb :
On 06/10/2014 06:51 PM, Patrick Domack wrote:
Quoting Axb :
On 06/10/2014 05:11 PM, Patrick Domack wrote:
There are all kinds of way to use the infomation. I just don't
understand why people are so against it, cause it's not 100% foolproof.
Nobody is against the idea, probl
On 06/10/2014 06:51 PM, Patrick Domack wrote:
Quoting Axb :
On 06/10/2014 05:11 PM, Patrick Domack wrote:
There are all kinds of way to use the infomation. I just don't
understand why people are so against it, cause it's not 100% foolproof.
Nobody is against the idea, problem is scalability
On Mon, 9 Jun 2014 22:44:22 +0200
Matthias Leisi wrote:
> I still have an experimental DNS server (written in Perl) lying
> around that this more-or-less what is described here. The overall
> system would need a bit more thought, though.
Attached is a hacky proof-of-concept script that stores st
Hi all,
I'm not very familiar with how to manage language encoding, and hoped
someone could help. Some time ago I wrote a rule that looks for subjects
that consist of a single word that's more than N characters. It works, but
I'm learning that it's performed before the content of the subject is
con
Quoting Axb :
On 06/10/2014 05:11 PM, Patrick Domack wrote:
There are all kinds of way to use the infomation. I just don't
understand why people are so against it, cause it's not 100% foolproof.
Nobody is against the idea, problem is scalability and trust.
To make domain age usable, the BLs
On 6/10/2014 2:27 AM, Christian Laußat wrote:
DKIM also had a policy method: ADSP. But it wasn't widely implemented
and is now the RFC status is now "historic". So maybe DMARC is then
new ADSP for DKIM?
That's the way I view it especially based on
http://www.dmarc.org/faq.html#g_4
What hap
On 06/10/2014 05:11 PM, Patrick Domack wrote:
There are all kinds of way to use the infomation. I just don't
understand why people are so against it, cause it's not 100% foolproof.
Nobody is against the idea, problem is scalability and trust.
To make domain age usable, the BLs I mentioned make
On 06/10/2014 04:34 PM, Patrick Domack wrote:
Quoting Axb :
On 06/10/2014 04:14 PM, Patrick Domack wrote:
Quoting Axb :
On 06/10/2014 12:28 PM, Patrick Domack wrote:
Not saying this doesn't happen. But also, how often does someone
register a domain, move all their users to the new domain,
Quoting Rob McEwen :
On 6/10/2014 10:21 AM, Axb wrote:
All URI BLs I know of (SURBL/URIBL/DBL/Invaluement/etc) check & track
domain reputation otherwise they'd be unusable.
Their listings are not blind - they all have their secret sauce to
process before listing a domain.
Absolutely. As Axb
On 6/10/2014 10:34 AM, Patrick Domack wrote:
> So, we are unwilling to look into any new ideas cause there might be
> an issue? that we haven't scoped or checked into?
Patrick,
I don't think Axe was arguing against this idea.. I think he was arguing
against irrational exuberance by some who may
On 6/10/2014 10:21 AM, Axb wrote:
> All URI BLs I know of (SURBL/URIBL/DBL/Invaluement/etc) check & track
> domain reputation otherwise they'd be unusable.
> Their listings are not blind - they all have their secret sauce to
> process before listing a domain.
Absolutely. As Axb and KAM and other
Quoting Axb :
On 06/10/2014 04:14 PM, Patrick Domack wrote:
Quoting Axb :
On 06/10/2014 12:28 PM, Patrick Domack wrote:
Not saying this doesn't happen. But also, how often does someone
register a domain, move all their users to the new domain, have the
server all reconfigured to use this n
On 06/10/2014 04:14 PM, Patrick Domack wrote:
Quoting Axb :
On 06/10/2014 12:28 PM, Patrick Domack wrote:
Not saying this doesn't happen. But also, how often does someone
register a domain, move all their users to the new domain, have the
server all reconfigured to use this new domain, all w
Quoting Axb :
On 06/10/2014 12:28 PM, Patrick Domack wrote:
Not saying this doesn't happen. But also, how often does someone
register a domain, move all their users to the new domain, have the
server all reconfigured to use this new domain, all within the first day?
I know personally, I have
On 06/10/2014 12:28 PM, Patrick Domack wrote:
Not saying this doesn't happen. But also, how often does someone
register a domain, move all their users to the new domain, have the
server all reconfigured to use this new domain, all within the first day?
I know personally, I have always taken at
On Tue, 10 Jun 2014, Axb wrote:
On 06/10/2014 12:17 AM, Philip Prindeville wrote:
nope... wiht robldnsd you set your BL zone to use the ip4trie
dataset
which as perhttp://www.corpit.ru/mjt/rbldnsd/rbldnsd.8.html
ip4trie Dataset Set of IP4 CIDR ranges with corresponding (A,
TXT) values. This
Quoting Lucio Chiappetti :
On Mon, 9 Jun 2014, Rob McEwen wrote:
Domain age is a good metric to factor in. But I'm always fascinated with
some people's desire to block all messages with extremely new domains.
Keep in mind that many large and famous businesses... who have fairly
good mail se
Yes, but you don't have to set p=reject to know how much mail you would
loose. That's what p=none monitoring mode is for.
And if you see that you will loose many mails from mailing lists, it is
not wise to change your policy to p=reject without fixing those problems
first.
It's not only mai
Because of the monitoring mode, when you move to p=reject, with all the
aggregate reports, you know exactly how much mail you will loose.
Only from reports coming from DMARC-checking mail servers that also
provide reports. You may well lose other mail delivery to servers that
fail to delive
On 06/10/2014 12:17 AM, Philip Prindeville wrote:
nope... wiht robldnsd you set your BL zone to use the ip4trie
dataset
which as perhttp://www.corpit.ru/mjt/rbldnsd/rbldnsd.8.html
ip4trie Dataset Set of IP4 CIDR ranges with corresponding (A,
TXT) values. This dataset is similar to ip4set, but
On Mon, 9 Jun 2014, Rob McEwen wrote:
Domain age is a good metric to factor in. But I'm always fascinated with
some people's desire to block all messages with extremely new domains.
Keep in mind that many large and famous businesses... who have fairly
good mail sending practices... sometimes
34 matches
Mail list logo
