We today received multiple requests from customers why legitimate Mails
are suddenly marked as Spam. After checking individual Mails the reason
where all the same:
Mailspike is blocking the IP 81.169.146.176 (= mo-p04-ob.rzone.de), a
heavy used Mailserver in Germany. This host is listed in dnswl
27;t found any Rule that does this. Anyone knows
a solution ?
Lutz Petersen
> > ip::country::fast is depricated alone since its not update with new ips, it
> > still
> > works if your still have ipv4 mailserver and self do updates with dbmscript
>
> On system A (SA 3.4) I removed Geo::IP and it now correctly resolves the
> Relay-Country as ES
> Looks like I will have t
Yust to your information:
The configuration requested by Darxus (and others) with the 'trusted_networks'
for the
ip's listed in http://dnswl.org/s?s=20763 now works as it should. Means, no
additional
HI negatives scores for mails that were received by *.mobile.de and then
forwarded.
> If you use mobile.de as a forwarder, it may make sense to add there IPs to
> your trusted_networks configuration. If you do this, the DNSxL tests are
> applied to the IP _before_ the mobile.de hop.
That is no problem special to us or our customers. The whitelist level for
the four mobile.de IPs
> It has nothing to do with where the spam originates. Either the server
> relays spam or it doesn't. Who cares if it comes from the customers or some
> 3rd party? If mobile.de has bad filters, it should be downgraded to LOW or
> NONE until they are fixed.
Henrik, you are right. I just made a
Because this is a systematic problem _and_ I don't wan't to change the default
SA
scores for dnswl for some reasons seems the only way to fight against this
special
problem is to write a local rule. This rule should check if mail from
mail.mobile.de
has been originated by them itself (then it i
> > Received: from unknown (HELO mail.mobile.de) (194.50.69.1)
> > Received: from derborse-fur-dummies.net (derborse-fur-dummies.net
> > [37.59.206.107])
> > by mail.mobile.de (Postfix) with ESMTP for
>
> by the way ,it looks like some newsletter, so your understanding of "spam"
> mi
Benny, even if we named equal - please read again, careful.
> > * 1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist
> > * [URIs: thebinarysistema.com]
> this test is domain based
That is no argument. Do you want to deactivate all SA rules that are not ip
based ??
> >Receiv
Seems misunderstanding. Better I give you a real example (shortend to be
readably and anonymous):
Return-Path:
* -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust
* [194.50.69.1 listed in list.dnswl.org]
* 1.7 URIBL_DBL_SPAM Contains an URL listed in the
> I can see no reports about *.mobile.de
The problem are _not_ mails from mobile.de (an ebay company) themselve.
There is no spam from this host and in that way the whitelisting is ok.
The problem is - you can create an email address and
let forward those mails to another addresses. All those m
ules. But
how to handle
those cases? Obviously this listing gives a lot of 'false negatives'. The only
way I see
seems to manually neutral this -5.0 scoring for all forwarded mails with a
local rule; but
then all mails that are originated by themselves would become tagged as spam
too. Does
Thanks, just deleted this rules.. ;)
We use this with really low scores - even if I can't remember of false
positives (not more than most others). I don't believe their false rate
reaches any of the others you mentioned (your bad note about spamcop
I don't understand, within the last months they
Maybe this would be something like that you want. It first checks the origin
country of an ip address (here limited to the 'well known' bad ones in africa).
The second step is a meta rule that first checks if mail comes from yahoo (both
webmail as smtp-login) and then look if the origin comes f
> >/^Received: from .41\..*web.*mail.*yahoo\.com via HTTP/i
> >
> >I admit this is rough albeit effective. On one side, not all Africa is
> >41. On the other side, I do not want to block all 41.
It seems that the hardcore users only resists in a limited amount of
netblocks, so it could make sens
> It would likely be a good idea to block IP's in this list from using
> authenticated SMTP to relay not?
Definitely not. We did so one week for testing. And had a lot of trouble with
customers espacially using mobile/smartphones.
Don't do this. This rbl does only make sense if you have diff
> > Wondering about this detection:
> >
> > "2.4 RDNS_NONE Delivered to internal network by a host with no
> > rDNS"
I saw this sometimes in mails delivered from external where people
have sent their mail within an internal lan to for example the
companies (internal reachable) mai
Maybe this question is stupid, but I get a bloody nose on this.
If one have header reports activated mostly the header entries
looks like this:
* x.x SENDER_IN_GBUDB RBL: Sender listed in truncate.gbudb.net
* [199.239.233.233 listed in truncate.gbudb.net]
Now I have some local rules (again
istings in their blacklists; but they
should never whitelist them too.
Lutz Petersen
I know some of the discussions in the past about usage of Sorbs RBLs
in Spamassassin. The scores today are as follows:
score RCVD_IN_SORBS_BLOCK 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_HTTP 0 2.499 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_MISC 0 # n=
20 matches
Mail list logo
