postfix and dns lookup
Matteo Cazzador
dns like (8.8.8.8) to resolve every domain (lookup for examples)
for incoming mail and outgoing mail. I don't want to use local dns on
postfix server is it possible?
Is it possible to use :
smtp_host_lookup = ?
Thank's a lot
--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
Le informazioni contenute in questa e-mail e nei files eventualmente allegati sono destinate unicamente ai destinatari della stessa e sono da considerarsi strettamente riservate. E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere il contenuto della presente senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 196/2003. Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.
******************************************
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
******************************************
Noel Jones
> Hello , i've a question , i want do configure postfix to use
> external dns like (8.8.8.8) to resolve every domain (lookup
> for examples)
> for incoming mail and outgoing mail. I don't want to use local
> dns on postfix server is it possible?
> Is it possible to use :
>
> smtp_host_lookup = ?
>
>
> Thank's a lot
>
If you don't want to use local DNS, then don't set any up.
Postfix uses whatever the system is configured to use in
/etc/resolv.conf.
There is no separate postfix config for setting a DNS resolver.
-- Noel Jones
Noel Jones
That said, it's really a mistake to not use any resolver at
all on anything bigger than a toy server.
At least set up a local caching resolver with 8.8.8.8 as the
forwarder.
-- Noel Jones
Matteo Cazzador
disable_dns_lookups=yes
to increase performance?
My postfix server is a virtual mail server
With mysql backend
--
Rispetta l'ambiente: se non ti ￜ necessario, non stampare questa mail.
Le informazioni contenute in questa e-mail e nei files eventualmente allegati sono destinate unicamente ai destinatari della stessa e sono da considerarsi strettamente riservate. E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere il contenuto della presente senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 196/2003. Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo immediatamente all'indirizzo mittente, nonchￜ di cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.
Ralf Hildebrandt
> Ok thank's in alternative is it possible use of
>
> disable_dns_lookups=yes
>
> to increase performance?
Uhm, your server probably won't be able to send out mail out after
that change, but at least it will do this quickly.
> My postfix server is a virtual mail server
> With mysql backend
What exactly IS your performance problem? Sending? Receiving? Local
delivery? How are you measuring?
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hil...@charite.de | http://www.charite.de
Matteo Cazzador
my local dns server , that is postfix server to, is used to filter
navigation of client (by domain black list)
so my local dns is under pressure and often mail give me error resolving
dns while sending mail to external.
I need to limitate this postfix error.
An example;
Out: 220 mydomain ESMTP Ermes
In: EHLO ciccio
Out: 250-mydomain
Out: 250-PIPELINING
Out: 250-SIZE 18000000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-AUTH LOGIN PLAIN
Out: 250-AUTH=LOGIN PLAIN
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: AUTH LOGIN
Out: 334 VXNlcm5hbWU6
In: aW5mb0BicnVub3NybC5uZXQ=
Out: 334 UGFzc3dvcmQ6
In: YXM4ZWUyNDU=
Out: 235 2.7.0 Authentication successful
In: MAIL FROM:<in...@mydomain.net>
Out: 250 2.1.0 Ok
In: RCPT TO:<daniela.mair@externaldomain>
Out: 451 4.3.0<daniela.mair@externaldomain>: Temporary lookup failure
In: RSET
Out: 250 2.0.0 Ok
thank's a lot
Il 04/02/2011 15:55, Ralf Hildebrandt ha scritto:
> * Matteo Cazzador<mat...@netlite.it>:
>> Ok thank's in alternative is it possible use of
>>
>> disable_dns_lookups=yes
>>
>> to increase performance?
> Uhm, your server probably won't be able to send out mail out after
> that change, but at least it will do this quickly.
>
>> My postfix server is a virtual mail server
>> With mysql backend
> What exactly IS your performance problem? Sending? Receiving? Local
> delivery? How are you measuring?
>
--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
Le informazioni contenute in questa e-mail e nei files eventualmente allegati sono destinate unicamente ai destinatari della stessa e sono da considerarsi strettamente riservate. E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere il contenuto della presente senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 196/2003. Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.
Ralf Hildebrandt
Please show the logs for exactly that error. Because the logs show
WHAT failed (DNS, or mysql lookups)
Matteo Cazzador
192.168.0.10 = internal client ip
now i've seen this strange mysql error maybe this is the real problem
Feb 4 00:00:58 localhost postfix/trivial-rewrite[2579]: warning: mysql
query failed: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and
(utf8_general_ci,COERCIBLE) for operation '='
Feb 4 00:00:58 localhost postfix/trivial-rewrite[2579]: warning:
transport_maps lookup failure
Feb 4 00:00:59 localhost postfix/trivial-rewrite[2579]: warning:
transport_maps lookup failure
Feb 4 00:00:59 localhost postfix/smtpd[2577]: NOQUEUE: reject: RCPT
from 189-93-193-156.3g.claro.net.br[189.93.193.156]: 451 4.3.0
<x@mydomain>: Temporary lookup failure; from=<?ngelL?p...@braun.org>
to=<x@mydomain> proto=SMTP helo=<189-93-193-156.3g.claro.net.br>
Feb 4 00:01:00 localhost postfix/trivial-rewrite[2579]: warning:
transport_maps lookup failure
Feb 3 12:53:54 localhost postfix/trivial-rewrite[29555]: warning: mysql
query failed: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and
(utf8_general_ci,COERCIBLE) for operation '='
Feb 3 12:53:54 localhost postfix/trivial-rewrite[29555]: warning:
transport_maps lookup failure
Feb 3 12:53:54 localhost postfix/trivial-rewrite[29555]: warning:
transport_maps lookup failure
Feb 3 12:54:22 localhost postfix/trivial-rewrite[29555]: warning:
transport_maps lookup failure
Feb 3 12:54:22 localhost postfix/smtpd[29552]: NOQUEUE: reject: RCPT
from unknown[192.168.0.10]: 451 4.3.0 <dan...@external.com>: Temporary
lookup failure; from=<in...@mydomain.net> to=<dan...@external.com>
proto=ESMTP helo=<ciccio>
Feb 3 12:54:55 localhost postfix/smtpd[29597]: disconnect from
unknown[192.168.0.10]
Feb 3 12:54:56 localhost postfix/smtpd[29618]: connect from
localhost[127.0.0.1]
Feb 3 12:54:56 localhost postfix/smtpd[29618]: 900EC47B3C:
client=localhost[127.0.0.1]
Feb 3 12:54:56 localhost postfix/cleanup[29561]: 900EC47B3C:
message-id=<1848812.827.1296734124609.JavaMail.SYSTEM@ciccio>
Feb 3 12:54:56 localhost postfix/smtp[29604]: 5779F47B3B:
to=<dan...@external.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.3,
delays=0.14/0/0/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=28949-16,
from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 900EC47B3C)
Feb 3 12:54:56 localhost postfix/qmgr[4415]: 5779F47B3B: removed
Feb 3 12:54:57 localhost postfix/smtp[29620]: 900EC47B3C: enabling PIX
workarounds: disable_esmtp delay_dotcrlf for
mail.external.com[external_ip]:25
Feb 3 12:55:00 localhost postfix/smtp[29620]: 900EC47B3C:
to=<dan...@external.com>, relay=mail.external.com[external_ip]:25,
delay=3.6, delays=0.1/0/0.89/2.6, dsn=2.0.0, status=sent (250 2.0.0
p1NNCbuA010097 Message accepted for delivery)
Feb 3 12:55:00 localhost postfix/qmgr[4415]: 900EC47B3C: removed
--
Ralf Hildebrandt
> hello here's my error log
> 192.168.0.10 = internal client ip
> now i've seen this strange mysql error maybe this is the real problem
Yes!
> Feb 4 00:00:58 localhost postfix/trivial-rewrite[2579]: warning: mysql query failed: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for
> operation '='
> Feb 4 00:00:58 localhost postfix/trivial-rewrite[2579]: warning: transport_maps lookup failure
> Feb 4 00:00:59 localhost postfix/trivial-rewrite[2579]: warning: transport_maps lookup failure
Reindl Harald
Am 04.02.2011 16:32, schrieb lst_...@kwsoft.de:
> So you have a local caching-resolver on the Postfix box?
>
> If so it should not fail because of traffic as long as your system resources are not exhausted.
> If your system resources are exhausted using a different resolver does not help.
>
> You might playing tricks with a local caching-resolver used by internal clients and
> pointing /etc/resolv.conf to
> some second (external) resolver but i doubt this is your problem at all
Even if dns-load would be the problem (which is not, it is mysql seen some posts before)
the real problem should be searched because nohting is better for a dns.cache as
a mailserver to get the cache filled
But i never seen any machine where dns-lookups where a load problem
Matteo Cazzador
warning: mysql query failed: Illegal mix of collations
(latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) operation '='
that cause
warning: transport_maps lookup failure
Someone suggest to forse use latin 1 in sql
like =CONVERT('%s' USING latin1) for mysql transport table
but is it correct?
In reality i don't use mysql-transport table can elide it.
--
Brian Evans - Postfix List
> Sure, thank's a lot everybody, i think the problem is related to:
>
> warning: mysql query failed: Illegal mix of collations
> (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE)
> operation '='
> that cause
>
> warning: transport_maps lookup failure
>
>
> Someone suggest to forse use latin 1 in sql
>
> like =CONVERT('%s' USING latin1) for mysql transport table
>
> but is it correct?
>
> In reality i don't use mysql-transport table can elide it.
http://dev.mysql.com/doc/refman/5.1/en/charset-literal.html
Postfix allows sql/ldap queries in transport_maps, but it is discouraged
for this very reason.
If you have a small list of transports, use a static hash/dbm/cdb lookup.
You can update these using a script if they are dynamic.
Don't postmap a hash transport table if it is quite long as overwrites
the old one in-line. Postmap to a temporary name or use cdb instead.
Benny Pedersen
wrote:
> At least set up a local caching resolver with 8.8.8.8 as the
> forwarder.
in case of bind this is bad to use any forwarder since it disables hint
zone, forwarders is more usefull pr zone, so keeep forwards out of options
containter in named.conf
Reindl Harald
And where is the problem?
Nobody needs the "hint zone" in his LAN because some reasons:
* A big external forwarder has many requests in his cache
* This cached requests are much faster and fewer as full recursion
* It reduces the load of the root-Servers
Matteo Cazzador
not dns
like i thinking of, the problem is caused by mysql backend. Some
spam has strange charset that caused mysql error, see previous mail
about it.
Thank's a lot.
--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
******************************************
Ing. Matteo Cazzador
NetLite Snc
di Gagliardi A. Cazzador M.
C.so Vittorio Emanuele II, 188
37069 Villafranca di Verona (VR)
Tel 045 4856656
Fax 045 4856655
C.F. E P.IVA 03782800233
Charles Marcus
> Am 05.02.2011 12:37, schrieb Benny Pedersen:
>> On Fri, 04 Feb 2011 08:44:39 -0600, Noel Jones<njo...@megan.vbhcs.org>
>> wrote:
>>> At least set up a local caching resolver with 8.8.8.8 as the
>>> forwarder.
>> in case of bind this is bad to use any forwarder since it disables hint
>> zone, forwarders is more usefull pr zone, so keeep forwards out of options
>> containter in named.conf
> And where is the problem?
> Nobody needs the "hint zone" in his LAN because some reasons:
>
> * A big external forwarder has many requests in his cache
> * This cached requests are much faster and fewer as full recursion
> * It reduces the load of the root-Servers
But you can't use one of the big public DNS resolvers if you are using
spamhaus or any of the other BLs...
Reindl Harald
>>> in case of bind this is bad to use any forwarder since it disables hint
>>> zone, forwarders is more usefull pr zone, so keeep forwards out of options
>>> containter in named.conf
>
>> And where is the problem?
>> Nobody needs the "hint zone" in his LAN because some reasons:
>>
>> * A big external forwarder has many requests in his cache
>> * This cached requests are much faster and fewer as full recursion
>> * It reduces the load of the root-Servers
>
> But you can't use one of the big public DNS resolvers if you are using
> spamhaus or any of the other BLs...
bullshit!
there is no difference if your stoopid nameserver makes recursion for
the request of your dns-client or the frowarder do this for him, think
about how works (google: recursion, ttl) and after that about your post
it is bad if every noob install his nameserver and configure it
for recursion because there are MANY requests, if you have some
clients in your lan this does not matter, but a amilserver
makes a lot of dns-requests
* your dns requests the root server
* root server gives him the address of the registry-server
* registry server tells you server the domain-dns
* finally your nameserver requests the authoritative one
if you are using a forwarder you leave the root-servers
fuck in peace and since most clients are using their isp
forwarder there is no single-point of load
Jeroen Geilman
> bullshit!
<snipped paragraphs of invective>
Way to make your case.
--
J.
Reindl Harald
sorry, but this was the only right answer for you can not
use dns-forwarder and blacklists"
http://www.postfix.org/TUNING_README.html
> Run a local name server to reduce slow-down due to DNS lookups.
> If you run multiple Postfix systems, point each local name server
> to a shared forwarding server to reduce the number of lookups
> across the upstream network link.
where does it interest your named if his forwarder is in
your lan or outside? there is no magic in dns
Ralf Hildebrandt
> > Way to make your case.
>
> sorry, but this was the only right answer for you can not
> use dns-forwarder and blacklists"
Well, you cannot use (for example) zen.spamhaus.org via 8.8.8.8 or
8.8.4.4
Noel Jones
>
>
> Am 05.02.2011 19:05, schrieb Jeroen Geilman:
>> On 2/5/11 6:58 PM, Reindl Harald wrote:
>>> bullshit!
>> <snipped paragraphs of invective>
>>
>>
>
> sorry, but this was the only right answer for you can not
> use dns-forwarder and blacklists"
The statement is conditionally true. Spamhaus and some other
blacklists don't work with most of the big ISP or public DNS
services due to excessive queries. There are workarounds
available.
This thread has run its course. Let's drop it here.
-- Noel Jones
Jeroen Geilman
>
> Am 05.02.2011 19:05, schrieb Jeroen Geilman:
>> On 2/5/11 6:58 PM, Reindl Harald wrote:
>>> bullshit!
>> <snipped paragraphs of invective>
>>
>>
>> Way to make your case.
> sorry, but this was the only right answer for you can not
> use dns-forwarder and blacklists"
I don't see any answer in there, not least because it wasn't parsable
English so much as a Tourette's stream-of-consciousness.
I suppose his reasoning was that querying a DNSBL through a forwarder
may fail for the simple reason that DNSBLs often have limits on a single
client requesting huge amounts of data. I know spamhaus does.
If you use a public internet forwarder for DNSBL queries, this may fail
simply because too many people use that same forwarder to query the same
DNSBL.
But I'm not him, so I can't know for sure if that was his meaning.
> http://www.postfix.org/TUNING_README.html
>> Run a local name server to reduce slow-down due to DNS lookups.
>> If you run multiple Postfix systems, point each local name server
>> to a shared forwarding server to reduce the number of lookups
>> across the upstream network link.
> where does it interest your named if his forwarder is in
> your lan or outside? there is no magic in dns
The quote above speaks specifically about using a shared forwarding
server *to reduce the number of lookups across the upstream network link*.
If you use a public forwarder, you are not reducing upstream network
lookups.
So, strictly speaking, he is right, and you're exploding up the wrong tree.
--
J.
/dev/rob0
wrote:
> hello, the nature of the problem that causes temporary lookup
> failure is not dns like i thinking of, the problem is caused
> by mysql backend. Some spam has strange charset that caused
> mysql error, see previous mail about it. Thank's a lot.
Right, but since your question in the OP was based on this
misdiagnosis, and the Subject line is regarding DNS, we are
talking about DNS here. :)
The charset conversion issue came up recently, 2011-01-24 to be
exact, and your answer is likely to fix the data in your database
(which is to say, it's directly not a Postfix issue.) See this
thread for details:
http://www.mail-archive.com/postfi...@postfix.org/msg31736.html
> Il 05/02/2011 13:55, Reindl Harald ha scritto:
> >Am 05.02.2011 12:37, schrieb Benny Pedersen:
> >>On Fri, 04 Feb 2011 08:44:39 -0600, Noel
> >>Jones<njo...@megan.vbhcs.org> wrote:
> >>
> >>>At least set up a local caching resolver with 8.8.8.8 as the
> >>>forwarder.
> >>in case of bind this is bad to use any forwarder since it
> >>disables hint zone, forwarders is more usefull pr zone, so keeep
> >>forwards out of options containter in named.conf
> >And where is the problem? Nobody needs the "hint zone" in his LAN
> >because some reasons:
> >
> >* A big external forwarder has many requests in his cache
> >* This cached requests are much faster and fewer as full recursion
> >* It reduces the load of the root-Servers
I'm not a DNS expert, far from it, but I know more than most people I
know, so sometimes I play one on the Internet. Here I go again, so
enjoy. :)
My understanding from BIND/DNS experts is that those three points are
false or moot.
> >* A big external forwarder has many requests in his cache
Perhaps so. And on average the TTL for cache hits will be roughly
half what you'd have when doing the recursion yourself.
> >* This cached requests are much faster and fewer as full recursion
Faster: possibly a bit. But if you have one locally-connected
recursive nameserver serving your network, its cache hits will be
quite a bit faster than any external nameserver.
Fewer: definitely not, because as above, on average you will see
roughly half the TTL.
> >* It reduces the load of the root-Servers
Maybe a little bit, yes. But most of those records have very long
TTL, which is designed to reduce the load. Don't go predicting gloom
and doom and the collapse of the Internet: it won't happen. The
global root is able to handle it.
Yes, a local caching nameserver using external forwarders might
present a few benefits. It's also potentially subject to cache
poisoning, and that being a cache which you do not control.
Recently I knew a NetworkSolutions-registered domain which expired
because of the registrant's oversight. NetSol redirects NS for
expired domains to some ns1/ns2.pendingrenewaldeletion.com. They set
a very long TTL for these NS records, at least 3 days, IIRC.
ns1.pendingrenewaldeletion.com. and its partner have a wildcard A
record for zone "." Try it, query any name you can think of:
this.is.fun.but.TLD.does.not.exist. 7200 IN A 209.62.105.19
The registrant was reached while on holiday and the domain renewed.
And yet, for days afterward, people were still asking why they were
getting that silly redirect page.
They were all using forwarders. Me, I flushed my DNS cache (rndc(8)'s
"flushname" subcommand) and got on with business as usual within an
hour after the payment went through.
To bring this almost back on topic, use of forwarders for zone "."
will mean, in many if not most cases, that queries to Spamhaus are
blocked, as Charles pointed out. Try it:
$ dig 2.0.0.127.zen.spamhaus.org. any @4.2.2.2 # Level3
$ dig 2.0.0.127.zen.spamhaus.org. any @8.8.4.4 # Google
Maybe *your* forwarder is not blocked yet. Have you seen what happens
when your Zen queries suddenly stop working? A few years back I had
MX on Comcast cable, and their nameservers were blocked without
warning, while I was gone for a few days. I returned to a massive
spam mess, of course.
Comcast, another good BAD example: they hijack all NXDOMAIN,
returning a wildcard A record. Wham, suddenly your DNSBL queries
return positive, and you're blocking everything!
Will your forwarder do something like this to you?
Will they notify you in advance of if if they do?
Will they warn you before Spamhaus starts blocking them?
Would they even know or care that they were blocked?
My mail is too important to be left to chance.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Reindl Harald
> Perhaps so. And on average the TTL for cache hits will be roughly
> half what you'd have when doing the recursion yourself.
but it's only ONE request and your are not the onnyl one
refreshing his caches
>>> * This cached requests are much faster and fewer as full recursion
>
> Faster: possibly a bit. But if you have one locally-connected
> recursive nameserver serving your network, its cache hits will be
> quite a bit faster than any external nameserver.
And my two nameservers in the network are cahcing the ansers
from the forwarder too - so what is the problem?
> Fewer: definitely not, because as above, on average you will see
> roughly half the TTL.
does not matter, se above
>>> * It reduces the load of the root-Servers
>
> Maybe a little bit, yes. But most of those records have very long
> TTL, which is designed to reduce the load. Don't go predicting gloom
> and doom and the collapse of the Internet: it won't happen. The
> global root is able to handle it.
there are not only root-servers involved
It makes a differnce fpr the tld-servers and finally for
the authoritative servers - you have only the half
of all what happens in your mind
> Yes, a local caching nameserver using external forwarders might
> present a few benefits. It's also potentially subject to cache
> poisoning, and that being a cache which you do not control.
nothing is perfect
> Recently I knew a NetworkSolutions-registered domain which expired
> because of the registrant's oversight. NetSol redirects NS for
> expired domains to some ns1/ns2.pendingrenewaldeletion.com. They set
> a very long TTL for these NS records, at least 3 days, IIRC.
cismet
> ns1.pendingrenewaldeletion.com. and its partner have a wildcard A
> record for zone "." Try it, query any name you can think of:
>
> this.is.fun.but.TLD.does.not.exist. 7200 IN A 209.62.105.19
so these are idiots
> To bring this almost back on topic, use of forwarders for zone "."
> will mean, in many if not most cases, that queries to Spamhaus are
> blocked, as Charles pointed out. Try it:
> $ dig 2.0.0.127.zen.spamhaus.org. any @4.2.2.2 # Level3
> $ dig 2.0.0.127.zen.spamhaus.org. any @8.8.4.4 # Google
>
> Maybe *your* forwarder is not blocked yet. Have you seen what happens
> when your Zen queries suddenly stop working?
spmahus *loool*
are there really peopole outside using them?
sorry, but since they blocked "nic.at", the registry for
austrian domains because spamhaus meant nic.at have to delete
a domain form where comes spam they are persona non grata
> A few years back I had
> MX on Comcast cable, and their nameservers were blocked without
> warning, while I was gone for a few days. I returned to a massive
> spam mess, of course.
http://www.barracudanetworks.com/ns/?L=de
Get a (virtual) appliance, their filters are fine and
their one blacklist does never block anybody
> Comcast, another good BAD example: they hijack all NXDOMAIN,
> returning a wildcard A record. Wham, suddenly your DNSBL queries
> return positive, and you're blocking everything!
again: everybody who configures a namesever this way is stoopid
> Will your forwarder do something like this to you?
if my ISP would touch any dns-answer he would not be my ISP
> Will they notify you in advance of if if they do?
no, but i would notify them!
> Will they warn you before Spamhaus starts blocking them?
again: it is braindead using blacklists from people
which are blocking a tld-registry without understand
nic.at can not delete a domain because some guy say
"soma is coming from there"
Stan Hoeppner
> But you can't use one of the big public DNS resolvers if you are using spamhaus
> or any of the other BLs...
Exactly why I installed pdns recursor on my MX about a year ago or so. I'd been
using my ISP's resolvers and began having problems with them. I switched to
Google's resolvers and Zen lookups broke. I then installed pdns recursor and
have had zero problems since, and much lower lookup latencies.
--
Stan
Stan Hoeppner
> http://www.barracudanetworks.com/ns/?L=de
>
> Get a (virtual) appliance, their filters are fine and
> their one blacklist does never block anybody
You speak of trust WRT to Spamhaus, which is the must trusted dnsbl outfit on
the planet, and has been for a long time.
Then you recommend an A/S appliance vendor whose products were the single
largest source of outscatter on the net for many years. It took years of
complaining and pleading by the community at large to get Barracuda to change
the default behavior, finally eliminating the outscatter.
I think I can safely speak for most seasoned mail OPs when I say Spamhaus has a
much higher degree of trust than Barracuda Networks.
--
Stan
Victor Duchovni
> You speak of trust WRT to Spamhaus [...]
Let's close the thread here. Not a good idea to debate whose RBL is
less evil on this list. Both are widely used, neither is evil enough
to warrant traffic here.
--
Viktor.
Reindl Harald
Am 05.02.2011 20:49, schrieb Stan Hoeppner:
> Reindl Harald put forth on 2/5/2011 12:49 PM:
>
>> http://www.barracudanetworks.com/ns/?L=de
>>
>> Get a (virtual) appliance, their filters are fine and
>> their one blacklist does never block anybody
>
> You speak of trust WRT to Spamhaus, which is the must trusted dnsbl outfit on
> the planet, and has been for a long time.
trustable?
type "spamhaus nic.at" in google
maybe there are few english documents out there
it is a no go to block a tld-registry
there is nothing to discuss
> Then you recommend an A/S appliance vendor whose products were the single
> largest source of outscatter on the net for many years. It took years of
> complaining and pleading by the community at large to get Barracuda to change
> the default behavior, finally eliminating the outscatter.
"default behavior" - what about lokk and configure a appliance
before take it online?
> I think I can safely speak for most seasoned mail OPs when I say Spamhaus has a
> much higher degree of trust than Barracuda Networks
and because there are much windows-users out tehre windows is a good os?
a blacklist which blocks large dns-forwarders?
jesus christ.....
http://www.uceprotect.net/en/rblcheck.php
no problem with 8.8.8.8 / 8.8.4.4
Benny Pedersen
wrote:
> And where is the problem?
spamhaus ? :-)
> Nobody needs the "hint zone" in his LAN because some reasons:
without the hint zone bind wont work
> * A big external forwarder has many requests in his cache
one problem is that a isp might just have 2 name servers, but my dns
hoster have 5, why not use it ?
> * This cached requests are much faster and fewer as full recursion
prove it :)
> * It reduces the load of the root-Servers
no, root severs delegate dns to ones isp servers ?, are you kidding ?
Reindl Harald
Am 05.02.2011 22:20, schrieb Benny Pedersen:
>> * It reduces the load of the root-Servers
>
> no, root severs delegate dns to ones isp servers ?, are you kidding ?
jesus christ what do you not understand that recursion needs
some dns-queries to find out what is the authoritative
nameserver and after that send a barindead request to this
if everybopdy out there would install a dns-server with full
recursion instead of caching forwarders as most do the load
on many dns-servers would be hughe larger
spamhaus does not intereset me
btw: this whole thread is off topic because the
topic is wrong since the thread-starter did
not realize that mysql was his problem