Benny,
Maybe I don't see your point clearly ;-) But I don't want to whitelist
URIHOSTS.
Have this two rules now
urirhssub URIBL_DOMAIN my.rbl.tld. A 127.0.0.16
bodyURIBL_DOMAIN eval:check_uridnsbl('MY_URIBL_DOMAIN')
askdns URIBL_HOST _URIHOSTS_.my.rbl.tld. A 12
Tobi skrev den 2018-02-19 14:43:
no need for this as that case is covered by sa urirhssub queries.
I needed a way to perform www.sub.domain.tld AND domain.tld queries of
the uri www.sub.domain.tld
would you like to test?
blacklist _URIDOMAINS_
whitelist _URIHOSTS_
:=)
if you score whitelist
Am 19.02.2018 um 14:25 schrieb Benny Pedersen:
> Tobi skrev den 2018-02-19 11:45:
> add one more askdns to compensate on _URIDOMAINS_
>
no need for this as that case is covered by sa urirhssub queries.
I needed a way to perform www.sub.domain.tld AND domain.tld queries of
the uri www.sub.domain
Am 19.02.2018 um 15:04 schrieb Benny Pedersen:
>
> yep got it, so if you only use URIHOSTS how do you know it does not miss
> in URIDOMAINS ?
I do not only use URIHOSTS but also a rhs lookup for just the domain.
So I have both bases covered :-)
Tobi skrev den 2018-02-19 14:45:
no need for this as that case is covered by sa urirhssub queries.
I needed a way to perform www.sub.domain.tld AND domain.tld queries of
the uri www.sub.domain.tld against by own rbl.
yep got it, so if you only use URIHOSTS how do you know it does not miss
in
Am 19.02.2018 um 14:25 schrieb Benny Pedersen:
> Tobi skrev den 2018-02-19 11:45:
> add one more askdns to compensate on _URIDOMAINS_
>
no need for this as that case is covered by sa urirhssub queries.
I needed a way to perform www.sub.domain.tld AND domain.tld queries of
the uri www.sub.domain.
Tobi skrev den 2018-02-19 11:45:
askdns MY_FULL_TEST_URIHOSTS_.my.rbl.tld A 127.0.0.4
which fires fullhost lookups according to spamassassin -D
its just that spammers would like you to do this :=)
i wont tell why its helping spammers
add one more askdns to compensate on _URIDOMA
lhost of an uri?
>
> Cheers
>
> Tobi
>
> - Originale Nachricht -
> Von: Daniele Duca
> Gesendet: 17.02.18 - 09:04
> An: jahli...@gmx.ch, users@spamassassin.apache.org
> Betreff: Re: Is there a way to perform selective full uri rbl lookups?
>
>> Hello,
&
users@spamassassin.apache.org
Betreff: Re: Is there a way to perform selective full uri rbl lookups?
> Hello,
>
> I do full uris dns lookups through a simple SA plugin. The core lines in
> the function are:
>
> sub check_fulluris {
> my ($self, $msg) = @_;
>
Hello,
I do full uris dns lookups through a simple SA plugin. The core lines in
the function are:
sub check_fulluris {
my ($self, $msg) = @_;
my $pms = $msg->{permsgstatus};
my $body = $msg->{msg}->get_pristine_body();
foreach my $this_url (uniq( $body =~
/(htt
jdow wrote:
>
>> By the way, is it possible to rescore or disable one rule, if another
>> already hit (thought on something like disabling bayes when
>> BOUNCE_MESSAGE
>> already hit)? This way I could disable Bayes when BOUNCE_MESSAGE already
>> hit. Yeah I know that's kind of bogus config but
From: "Daniel Lemke"
Sent: Friday, 2010/July/02 06:36
Matus UHLAR - fantomas wrote:
apparently not enough of NDRs. I trained bayes with many notices and it
was
able to detect as expected then.
It apparently does learn the ndrs given, but as we send a newsletter from
time to time (that produ
Matus UHLAR - fantomas wrote:
>
> apparently not enough of NDRs. I trained bayes with many notices and it
> was
> able to detect as expected then.
>
It apparently does learn the ndrs given, but as we send a newsletter from
time to time (that produces ndrs as well), Bayes seems to learn ndrs as
> Matus UHLAR - fantomas wrote:
> > the first can be catched by using ok_locales
On 30.06.10 04:14, Daniel Lemke wrote:
> We are already using ok_locales, but it does not score all of the mail and
> if it scores, the few points at all are not enough to identify it as spam
> (since bayes still scor
Daniel Lemke wrote:
> For a short time we receive several hundreds of non delivery
> notifications and other failure notices on one of our mailboxes.
> Most of them look very similar, containing Cyrillic charset and .ru
> addresses.
> Are there any special rules that are able to identify this kin
On Wed, 2010-06-30 at 02:02 -0700, Daniel Lemke wrote:
> For a short time we receive several hundreds of non delivery notifications
> and other failure notices on one of our mailboxes.
> Most of them look very similar, containing Cyrillic charset and .ru
> addresses.
> Are there any special rules t
On Wed, 30 Jun 2010 06:19:45 -0700 (PDT)
Daniel Lemke wrote:
>
>
> Arvid Picciani wrote:
> >
> > We block them at MTA level using subject matching and
> > http://www.backscatterer.org/
> > Although we block _all_ NDAs, and only whitelist some that are
> > explicitly requested by $boss. May or
John Hardin wrote:
>
> Publishing SPF records for your domain may reduce this. Spammers _appear_
> to avoid forging sender addresses from domains that publish SPF
> information.
>
We do have a valid SPF record:
Found v=spf1 record for jam-software.com:
v=spf1 a mx mx ip4:212.18.213.197 ip4:
Arvid Picciani wrote:
>
> We block them at MTA level using subject matching and
> http://www.backscatterer.org/
> Although we block _all_ NDAs, and only whitelist some that are
> explicitly requested by $boss. May or may not suit your needs.
>
I'll have a look into this, thanks for the hint.
D
On Wed, 30 Jun 2010, Daniel Lemke wrote:
For a short time we receive several hundreds of non delivery
notifications and other failure notices on one of our mailboxes.
Publishing SPF records for your domain may reduce this. Spammers _appear_
to avoid forging sender addresses from domains that
Karsten Bräckelmann-2 wrote:
>
> It is a bounce, backscatter. It is not spam. It should not be treated as
> such, and a lot of (spam) tests won't trigger on them.
>
Some definitions of spam include backscatter/bounce as well... but you're
right, they shouldn't.
> Have you tried it? Configure
On Wed, 30 Jun 2010 02:02:51 -0700 (PDT), Daniel Lemke
wrote:
> Are there any special rules that are able to identify this kind of spam?
Its not spam, its misconfigured mailservers. Stupid people and
malicious people are two different problems. Don't let bayes learn it as spam.
We block them at
On Wed, 2010-06-30 at 04:14 -0700, Daniel Lemke wrote:
> [...] I already trained bayes with hundreds
> of mails, but it still doesn't recognize this ndr as spam.
It is a bounce, backscatter. It is not spam. It should not be treated as
such, and a lot of (spam) tests won't trigger on them.
> > Fo
On Wed, 2010-06-30 at 02:02 -0700, Daniel Lemke wrote:
> For a short time we receive several hundreds of non delivery notifications
> and other failure notices on one of our mailboxes.
>
You've been joe jobbed by a spammer who forged your address as the
sender of his junk and then randomly generate
Matus UHLAR - fantomas wrote:
>
> the first can be catched by using ok_locales
>
We are already using ok_locales, but it does not score all of the mail and
if it scores, the few points at all are not enough to identify it as spam
(since bayes still scores negative). I already trained bayes with
On 30.06.10 02:02, Daniel Lemke wrote:
> For a short time we receive several hundreds of non delivery notifications
> and other failure notices on one of our mailboxes.
> Most of them look very similar, containing Cyrillic charset and .ru
> addresses.
the first can be catched by using ok_locales
John Hardin wrote:
>>
>> No, the message is queued first, then passed to spamd.
>
> In that case I can't understand why there would not be a local
> Received: header.
>
Yeah ...
>
MISSING_DATE,MISSING_HEADERS,MISSING_MID,MISSING_SUBJECT,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS
>
> Wow.
>
> I
On Tue, 1 Dec 2009, Per Jessen wrote:
John Hardin wrote:
On Mon, 30 Nov 2009, Per Jessen wrote:
John Hardin wrote:
That proxy shouldn't pass a message to spamd unless it has a
Received: header, and I would suggest that it should not pass a
message to spamd unless it has a Received header t
Matus UHLAR - fantomas wrote:
>> > Seeing the headers from one of these would be helpful, can you post
>> > a sample? Body not needed. What I'm looking for is the presence of
>> > any Received: header not added by _your_ MTA. I would wager that
>> > the problematic messages when examined in your q
> John Hardin wrote:
> > What's odd here is it sounds like you're describing messages that have
> > been received from a third-party MTA rather than an external MUA, so
> > they _should_ have a Received: header added by that MTA.
On 01.12.09 08:50, Per Jessen wrote:
> Yes, most would be coming fro
John Hardin wrote:
> On Mon, 30 Nov 2009, Per Jessen wrote:
>
>> John Hardin wrote:
>>
>>> That proxy shouldn't pass a message to spamd unless it has a
>>> Received: header, and I would suggest that it should not pass a
>>> message to spamd unless it has a Received header that was added by
>>> th
On Mon, 30 Nov 2009, Per Jessen wrote:
> John Hardin wrote:
>
> > That proxy shouldn't pass a message to spamd unless it has a Received:
> > header, and I would suggest that it should not pass a message to spamd
> > unless it has a Received header that was added by the local MTA;
>
> A message wil
On Mon, 30 Nov 2009, Per Jessen wrote:
John Hardin wrote:
That proxy shouldn't pass a message to spamd unless it has a Received:
header, and I would suggest that it should not pass a message to spamd
unless it has a Received header that was added by the local MTA;
A message will always have
John Hardin wrote:
> That proxy shouldn't pass a message to spamd unless it has a Received:
> header, and I would suggest that it should not pass a message to spamd
> unless it has a Received header that was added by the local MTA;
A message will always have one of those. That is what is so
mind
On Mon, 30 Nov 2009, Per Jessen wrote:
On 30.11.09 16:41, Per Jessen wrote:
Anyway, how about a way to make spamd refuse to process a message
when it appears to to have any?
MTA is postfix, I call spamd directly using the spamc protocol (but
not spamc).
I have my own smtp proxy which calls
Matus UHLAR - fantomas wrote:
>> > On 30.11.09 16:41, Per Jessen wrote:
>> >> I could, but it won't help - rest assured it has the headers.
>> >> Anyway, how about a way to make spamd refuse to process a message
>> >> when it appears to to have any?
>
>> Matus UHLAR - fantomas wrote:
>> > which M
> > On 30.11.09 16:41, Per Jessen wrote:
> >> I could, but it won't help - rest assured it has the headers.
> >> Anyway, how about a way to make spamd refuse to process a message
> >> when it appears to to have any?
> Matus UHLAR - fantomas wrote:
> > which MTA do you use? How do you plug SA in?
Per Jessen wrote:
> Matus UHLAR - fantomas wrote:
>
>> On 30.11.09 16:41, Per Jessen wrote:
>>> I could, but it won't help - rest assured it has the headers.
>>> Anyway, how about a way to make spamd refuse to process a message
>>> when it appears to to have any?
>>
>> which MTA do you use? How
Matus UHLAR - fantomas wrote:
> On 30.11.09 16:41, Per Jessen wrote:
>> I could, but it won't help - rest assured it has the headers.
>> Anyway, how about a way to make spamd refuse to process a message
>> when it appears to to have any?
>
> which MTA do you use? How do you plug SA in?
MTA is p
> d.h...@yournetplus.com wrote:
>
> > Quoting Per Jessen :
> >
> >> d.h...@yournetplus.com wrote:
> >>
> >>> Quoting Per Jessen :
> >>>
> I seem to be having more emails with NO_RELAYS than I normally see,
> and
> I'd like to havee spamd just refuse to process them. That way
> >>>
d.h...@yournetplus.com wrote:
> Quoting Per Jessen :
>
>> d.h...@yournetplus.com wrote:
>>
>>> Quoting Per Jessen :
>>>
I seem to be having more emails with NO_RELAYS than I normally see,
and
I'd like to havee spamd just refuse to process them. That way
they'd get left in the
Quoting Per Jessen :
d.h...@yournetplus.com wrote:
Quoting Per Jessen :
I seem to be having more emails with NO_RELAYS than I normally see,
and
I'd like to havee spamd just refuse to process them. That way they'd
get left in the queue, and I'd have something to debug.
NO_RELAYS indicates
d.h...@yournetplus.com wrote:
> Quoting Per Jessen :
>
>> I seem to be having more emails with NO_RELAYS than I normally see,
>> and
>> I'd like to havee spamd just refuse to process them. That way they'd
>> get left in the queue, and I'd have something to debug.
>
> NO_RELAYS indicates there a
Quoting Per Jessen :
I seem to be having more emails with NO_RELAYS than I normally see, and
I'd like to havee spamd just refuse to process them. That way they'd
get left in the queue, and I'd have something to debug.
NO_RELAYS indicates there are no Received headers:
http://wiki.apache.
> -Original Message-
> From: Peter M. Abraham [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 09, 2006 5:30 PM
> To: users@spamassassin.apache.org
> Subject: Is there a way to tell spam assassin to avoid any processing of
> local emails?
>
>
>
> ___
On Sat, 9 Dec 2006, Peter M. Abraham wrote:
> Is there a way to tell Spam Assassin (SpamAssassin 3.1.7) to skip
> processing emails sent from our network (public IP addresses are
> involved)?
>
> I do have TrustedNeworks set up, but I don't know if there is
> another variable that must also be se
On Sat, Dec 09, 2006 at 10:30:25AM -0500, Peter M. Abraham wrote:
> Is there a way to tell Spam Assassin (SpamAssassin 3.1.7) to skip processing
> emails sent from our network (public IP addresses are involved)?
No. SpamAssassin scans anything sent to it. The only way to skip processing
is to no
In my case the rule is designed to catch UK recruiters who are always
contacting me.
This isn't the only way I trap spam obviously.
Another thing I just realized is that this only looks for URI's in
the email itself in order to determine if they reside in the UK.
Something different from R
>>
>> Here's the solution I use
>>
>> loadplugin Mail::SpamAssassin::Plugin::URICountry
>>
>> uricountry URICOUNTRY_GB GB
>> header URICOUNTRY_GB eval:check_uricountry('URICOUNTRY_GB')
>> describeURICOUNTRY_GB Contains a URI hosted in GB
>> tflags URICOUNTRY_
Benny Pedersen wrote:
header URICOUNTRY_GB eval:check_uricountry('URICOUNTRY_GB')
what if a spammer sends mails from another ip outside GB ?
imho such rules only changes the problem, not solving it :(
URICOUNTRY scores on spams that URIs hosted in a given country rather
than spam tha
On Sat, November 11, 2006 02:31, Robert Nicholson wrote:
> header URICOUNTRY_GB eval:check_uricountry('URICOUNTRY_GB')
what if a spammer sends mails from another ip outside GB ?
imho such rules only changes the problem, not solving it :(
--
"This message was sent using 100% recycled spam mail
Here's the solution I use
loadplugin Mail::SpamAssassin::Plugin::URICountry
uricountry URICOUNTRY_GB GB
header URICOUNTRY_GB eval:check_uricountry('URICOUNTRY_GB')
describeURICOUNTRY_GB Contains a URI hosted in GB
tflags URICOUNTRY_GB net
score URICOUNTRY_G
Daryl C. W. O'Shea wrote on Thu, 08 Jun 2006 17:50:33 -0400:
> I agree that outright blocking based on dynamic IP range lists often
> doesn't suite a particular organizations needs. I was just pointing out
> that some people do rely on these lists, often blindly, and that anyone
> who is aware
Kai Schaetzl wrote:
Daryl C. W. O'Shea wrote on Thu, 08 Jun 2006 11:46:48 -0400:
Still, when your ISP isn't responsive
As Chris says you better move away from them then if you can. If you can't
I'd really bother them day and night since I don't get what I paid for. My
Over the years, for
Daryl C. W. O'Shea wrote on Thu, 08 Jun 2006 11:46:48 -0400:
> Still, when your ISP isn't responsive
As Chris says you better move away from them then if you can. If you can't
I'd really bother them day and night since I don't get what I paid for. My
IP range was once listed at SORBS as well, t
> -Original Message-
> From: John D. Hardin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 08, 2006 12:33 PM
> To: Greg Allen
> Cc: [EMAIL PROTECTED] Apache. Org
> Subject: RE: is there a way to block email coming from
>
>
> On Thu, 8 Jun 2006, Greg Allen wr
On Thu, 8 Jun 2006, Greg Allen wrote:
> There are a lot of small businesses on these legitimate business
> class DSL lines with fixed IP addresses (which they pay extra for)
> who are very frequently incorrectly listed as "dynamic" IP
> addresses. The vast majority of these small companies are NOT
Kai Schaetzl wrote:
Daryl C. W. O'Shea wrote on Thu, 08 Jun 2006 01:18:11 -0400:
Some even with T1s (probably quietly provisioned over
DSL) that have IPs smack in the middle of static business DSL ranges
that are listed in SORBS' dynamic list.
Nevertheless, it's their ISP's fault and if they
Title: RE: is there a way to block email coming from
> -Original Message-
> From: Greg Allen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 08, 2006 12:05 AM
> To: [EMAIL PROTECTED] Apache. Org
> Subject: RE: is there a way to block email coming from
>
>
&g
John D. Hardin wrote on Wed, 7 Jun 2006 20:41:38 -0700 (PDT):
> The greatest drawback is that using the RBL within sendmail is an
> all-or-nothing proposition. What if you *do* have legitimate
> correspondents in those countries?
You can still whitelist these in access.db.
Kai
--
Kai Schätzl
Greg Allen wrote on Thu, 8 Jun 2006 00:05:12 -0400:
> They probably don't have a full time IT staff.
They don't need one for getting unlisted.
> There are a lot of small businesses on these legitimate business class DSL
> lines with fixed IP addresses (which they pay extra for) who are very
>
Daryl C. W. O'Shea wrote on Thu, 08 Jun 2006 01:18:11 -0400:
> Some even with T1s (probably quietly provisioned over
> DSL) that have IPs smack in the middle of static business DSL ranges
> that are listed in SORBS' dynamic list.
Nevertheless, it's their ISP's fault and if they remain on the li
mail. We on the other hand mark it up and pass it on.
So my rant now is SORBS is starting to suck...
> -Original Message-
> From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 07, 2006 10:18 PM
> To: [EMAIL PROTECTED] Apache. Org
> Subject: R
On 6/8/2006 12:05 AM, Greg Allen wrote:
However, the ISP dynamic address tests *do* belong in the MTA RBL
checks. The fraction of legitimate emails received from dynamic-IP
hosts is vanishingly small compared to the tens or hundreds of
thousands of compromised Windows boxen spewing spam and virus
>
> However, the ISP dynamic address tests *do* belong in the MTA RBL
> checks. The fraction of legitimate emails received from dynamic-IP
> hosts is vanishingly small compared to the tens or hundreds of
> thousands of compromised Windows boxen spewing spam and viruses...
>
Sorry to poke in on th
On Wed, 7 Jun 2006, Steven W. Orr wrote:
> On Wednesday, Jun 7th 2006 at 09:53 -0700, quoth John D. Hardin:
>
> =>On Wed, 7 Jun 2006, Screaming Eagle wrote:
> =>
> =>> country, other than USA? How would you look up the network block
> =>> on country such as Romania, China, Taiwan,Thailand, Korea
On Wednesday, Jun 7th 2006 at 09:53 -0700, quoth John D. Hardin:
=>On Wed, 7 Jun 2006, Screaming Eagle wrote:
=>
=>> country, other than USA? How would you look up the network block
=>> on country such as Romania, China, Taiwan,Thailand, Korea, and so
=>> on...
=>
=>describe BL_COUNTRY_TW_1 Mail
You can also block specific ISPs, with varying degrees of reliability.
For example:
describe BL_COUNTRY_FR_2 Mail client in France
header BL_COUNTRY_FR_2 eval:check_rbl('wanadoo-fr',
'wanadoo-fr.blackholes.us')
scoreBL_COUNTRY_FR_2 0.5
tflags BL_COUNTRY_FR_2 net
Wanadoo is a French ISP
On Wed, 7 Jun 2006, Screaming Eagle wrote:
> Is BL_COUNTRY_TW_1 for all country? "Mail client in Taiwan" is an arg value?
> If so, then this Synthax would be o.k:
> describe BL_COUNTRY_TW_1 Mail client in Korea?
Sorry, I assumed you were familiar with the syntax of rules in SA.
> On 6/7/06, John
Is BL_COUNTRY_TW_1 for all country? "Mail client in Taiwan" is an arg value? If so, then this Synthax would be o.k:
describe BL_COUNTRY_TW_1 Mail client in Korea?
Thanks.On 6/7/06, John D. Hardin <[EMAIL PROTECTED]> wrote:
On Wed, 7 Jun 2006, Screaming Eagle wrote:> country, other than USA? How
> country, other than USA? How would you look up the network block on
> country
> such as Romania, China, Taiwan,Thailand, Korea, and so on...
>
> Thanks.
Check out http://countries.nerd.dk/ and http://www.blackholes.us/
On Wed, 7 Jun 2006, Screaming Eagle wrote:
> country, other than USA? How would you look up the network block
> on country such as Romania, China, Taiwan,Thailand, Korea, and so
> on...
describe BL_COUNTRY_TW_1 Mail client in Taiwan
header BL_COUNTRY_TW_1 eval:check_rbl('taiwan', 'tw.countries
>-Original Message-
>From: Mário Gamito [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, September 28, 2004 5:18 AM
>To: users@spamassassin.apache.org
>Subject: Is there a way...
>
>
>... to prevent a single and specific account only to be parsed by
>spamassassin ?
>
>Any help would be apprecia
73 matches
Mail list logo
