On 12/13/11 3:35 PM, R - elists wrote:
greetings
how are you folks on this list dealing with unwanted solicitations from
companies that spam via netsuite.com ?
-rh
don't see them... I guess SA marks them spam :-)
but, I suppose it's no different than sugarcrm or salesforce (I dropped
sale
I used several years worth of notes to come up with the information
below. It needs more polish and it is my very first rip and shred.
I am also certain that I've missed some great points others have
made.
So I am posting this to solicit feedback on this draft so I
On Tue, 2011-12-13 at 15:33 -0500, David F. Skoll wrote:
> I think something like this would be good:
>
> $ tar xvfz Mail-SpamAssassin-xxx.tar.gz
> $ cd Mail-SpamAssassin-xxx
> $ perl Makefile.PL
> [...]
>
> The following RBLs have certain usage restrictions. Would you like to
> enable them? If
greetings
how are you folks on this list dealing with unwanted solicitations from
companies that spam via netsuite.com ?
-rh
On Tue, 13 Dec 2011 15:24:34 -0500
dar...@chaosreigns.com wrote:
> If you can come up with a way to disable all network tests that have
> a free use limit without crippling spamassassin, please tell us.
> That would be lovely.
I think something like this would be good:
$ tar xvfz Mail-SpamAssass
On 12/13, Kevin A. McGrail wrote:
> Is there a formal policy for including (or excluding) DNS-based lists
whats
>There is formal consensus from the PMC that ^ work^ for most installations
> is
>adequate for default inclusion once the mer
On 12/13/2011 2:00 PM, David F. Skoll wrote:
Hi,
Is there a formal policy for including (or excluding) DNS-based lists
from SpamAssassin's default rules? I think that SpamAssassin should
not enable any DNS-based list by default unless the list owners have a
clear policy that the list is free to
Hi,
Is there a formal policy for including (or excluding) DNS-based lists
from SpamAssassin's default rules? I think that SpamAssassin should
not enable any DNS-based list by default unless the list owners have a
clear policy that the list is free to use by SpamAssassin users,
regardless of query
I don't think there really needs to be consensus. I've yet to see one
that blocks 127.0.0.1, and they all have some sort of test address
(usually 127.0.0.x)
Given that the worst that happens if this system fails is that SA
stops using the list until sa-update updates the check rule, as long
On 12/13/2011 10:37 AM, Kevin A. McGrail wrote:
This system would result in one query per BL per SA restart, or per
ruleset reload or per hour or whatever, rather than one or more
queries per processed message. That's a step forward to DNSBL
operators, but more importantly, it would avoid the
This system would result in one query per BL per SA restart, or per
ruleset reload or per hour or whatever, rather than one or more
queries per processed message. That's a step forward to DNSBL
operators, but more importantly, it would avoid the situation where
users are negatively impacted b
On 12/13/2011 5:44 AM, Kevin A. McGrail wrote:
On 12/13/2011 2:19 AM, Dave Warren wrote:
On 12/12/2011 5:27 PM, Karsten Bräckelmann wrote:
No. SA should be usable out-of-the-box with best possible performance
for the majority of users.
Perhaps a better long-term solution would be to validate
On 12/13/2011 9:21 AM, David F. Skoll wrote:
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocke
On Tue, 13 Dec 2011 14:09:19 +
Martin Gregorie wrote:
> At the risk of exposing my ignorance, I had a thought.
>
> Since the entire 127/8 is reserved for loopback, nothing in the
> 127.0.0/24 block should be used as addresses. So, what is preventing
> RBLs and RWLs from using the third octe
On 2011-12-13 15:21, David F. Skoll wrote:
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocked
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocked and NXDOMAIN
for others. This might even work
On Tue, 13 Dec 2011, Kevin A. McGrail wrote:
On 12/13/2011 2:19 AM, Dave Warren wrote:
Perhaps a better long-term solution would be to validate DNS lists before
using them?
One possible implementation would be to test to ensure that 127.0.0.1
is not listed
Similarly, 127.0.0.1 should nev
On Tue, Dec 13, 2011 at 3:00 PM, Michael Scheidell
wrote:
> [..] Blocking the ip address by firewall
> will save bandwidth and cpu cycles.
Firewalling will have the same effect as returning no answer - it will
cause retries and thus will roughly triple the amount of queries
received (although th
On 12/13/11 8:09 AM, "Martin Gregorie" wrote:
> On Tue, 2011-12-13 at 13:52 +0100, Axb wrote:
>> On 2011-12-13 13:44, Kevin A. McGrail wrote:
If a list is down or unresponsive for any reason, discards requests or
blanks their zone file, the test entry would fail and SA would know to
On Tue, 13 Dec 2011 08:47:18 -0500
Michael Scheidell wrote:
> On 12/13/11 3:38 AM, Raymond Dijkxhoorn wrote:
> > Hi!
> >
> > Easiest way would be putting them inside a uribl.
> >
> > Whats the reason to get on this list?
> > Eg what policy?
> The policy is clearly stated on their web site, first p
On Tue, 2011-12-13 at 13:52 +0100, Axb wrote:
> On 2011-12-13 13:44, Kevin A. McGrail wrote:
> >> If a list is down or unresponsive for any reason, discards requests or
> >> blanks their zone file, the test entry would fail and SA would know to
> >> not use the list. Similarly, 127.0.0.1 should nev
On 12/13/11 7:44 AM, Kevin A. McGrail wrote:
Blocking seems to be the only thing that really achieves the goal
they want beyond conversion to paying customers which is not SA's issue.
I agree with Kevin.
A while back, I published an 'example' blocking list,
'blocked.secnap.net' (wildcard e
On 12/13/11 3:38 AM, Raymond Dijkxhoorn wrote:
Hi!
Easiest way would be putting them inside a uribl.
Whats the reason to get on this list?
Eg what policy?
The policy is clearly stated on their web site, first paragraph of that
link.
I believe it is a private list, not meant to be used for spa
On 2011-12-13 13:44, Kevin A. McGrail wrote:
On 12/13/2011 2:19 AM, Dave Warren wrote:
On 12/12/2011 5:27 PM, Karsten Bräckelmann wrote:
No. SA should be usable out-of-the-box with best possible performance
for the majority of users.
Perhaps a better long-term solution would be to validate DN
On 12/13/2011 2:19 AM, Dave Warren wrote:
On 12/12/2011 5:27 PM, Karsten Bräckelmann wrote:
No. SA should be usable out-of-the-box with best possible performance
for the majority of users.
Perhaps a better long-term solution would be to validate DNS lists
before using them?
One possible imp
On 2011-12-13 8:34, Michael Monnerie wrote:
On Montag, 31. Oktober 2011 Axb wrote:
tried it and dumped due to low hit rate
stuff like
body ZMIde_JOBSEARCH6 /Dank sehr grossen Angagement, aber auch
der Umsetzung verschiedener Inovationen, konnte unsere Firma schon
nach vier Jahren auf die
Hi!
Easiest way would be putting them inside a uribl.
Whats the reason to get on this list?
Eg what policy?
Thanks,
Raymond Dijkxhoorn, Prolocation
Op 13 dec. 2011 om 08:54 heeft Tom Kinghorn het
volgende geschreven:
> Good morning List.
>
> The nice guys at Rhyolite.com have a list of unw
27 matches
Mail list logo
