> In message <20101112143542.ga23...@fantomas.sk>, Matus UHLAR - fantomas
> writes:
> > what about check-mx setting, can it be also affected by this setting?
On 13.11.10 10:56, Mark Andrews wrote:
> As I said it is a easy fix. This just copies what the srv check does.
shall this be included in
In message <20101112143542.ga23...@fantomas.sk>, Matus UHLAR - fantomas writes:
> > In message <20101112135657.gb22...@fantomas.sk>, Matus UHLAR - fantomas wri
> tes:
> > > On 29.10.10 12:49, Mark Andrews wrote:
> > > > And they can do a SMTP level rejection rather than waiting for the
> > > > sen
> In message <20101112135657.gb22...@fantomas.sk>, Matus UHLAR - fantomas
> writes:
> > On 29.10.10 12:49, Mark Andrews wrote:
> > > And they can do a SMTP level rejection rather than waiting for the
> > > sending server to abandon sending the email due to multiple timeouts.
> > > Just return 550
In message <20101112135657.gb22...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 29.10.10 12:49, Mark Andrews wrote:
> > And they can do a SMTP level rejection rather than waiting for the
> > sending server to abandon sending the email due to multiple timeouts.
> > Just return 550 for all mail
On 29.10.10 12:49, Mark Andrews wrote:
> And they can do a SMTP level rejection rather than waiting for the
> sending server to abandon sending the email due to multiple timeouts.
> Just return 550 for all mail directed to users at those hosts. It
> would be nice if we could standardise a MX targ
On Fri, 29 Oct 2010, Mark Andrews wrote:
>
> It would be nice if we could standardise a MX target of "." as saying
> that this domain doesn't accept email e.g. "MX 0 ." the same way as "SRV
> 0 0 0 ." means that there is no service for the named protocol. That
> way the sending MTA or the MSA can
On Thu, 28 Oct 2010, Fr34k wrote:
>
> Why not use " IN MX 100 localhost" so the email doesn't even leave the source?
That will usually lead to delays, just like having no MX at all.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST
I'd like to suggest an alternative reason for the presence of those records:
The Perl script H2N will install them by default for every single host in
the zone file, unless you use the -M option to suppress their creation.
Obviously this has nothing to do with the value, or lack thereof, of those
In message <458977.96237...@web53606.mail.re2.yahoo.com>, Fr34k writes:
> > In message , Barr
> y
> >Mar
> > golin writes:
> > > In article ,
> > > Tony Finch wrote:
> > >
> > > > On Thu, 28 Oct 2010, Gregory Machin wrote:
> > > > >
> > > > > My question is why would "INMX10 mc
- Original Message
> From: Mark Andrews
> To: Barry Margolin
> Cc: comp-protocols-dns-b...@isc.org
> Sent: Thu, October 28, 2010 9:49:46 PM
> Subject: Re: out of place mx records.
>
>
> In message , Barry
>Mar
> golin writes:
> >
In message , Barry Mar
golin writes:
> In article ,
> Tony Finch wrote:
>
> > On Thu, 28 Oct 2010, Gregory Machin wrote:
> > >
> > > My question is why would "INMX10mcvpemr01" and "INMX
> > > 10mcvpemr02" be repeated trough the zone file surely this is
> > > redundant ?
> >
In article ,
Tony Finch wrote:
> On Thu, 28 Oct 2010, Gregory Machin wrote:
> >
> > My question is why would "INMX10mcvpemr01" and "INMX
> > 10mcvpemr02" be repeated trough the zone file surely this is
> > redundant ?
>
> Some hostmasters like to ensure that mail is not dir
On 28/10/10 11:56, Tony Finch wrote:
On Thu, 28 Oct 2010, Gregory Machin wrote:
My question is why would "INMX10mcvpemr01" and "INMX
10mcvpemr02" be repeated trough the zone file surely this is
redundant ?
Some hostmasters like to ensure that mail is not directed to host
On Thu, 28 Oct 2010, Gregory Machin wrote:
>
> My question is why would "INMX10mcvpemr01" and "INMX
> 10mcvpemr02" be repeated trough the zone file surely this is
> redundant ?
Some hostmasters like to ensure that mail is not directed to hosts that do
not listen on SMTP. They
Hello Gregory,
Thu, 28 Oct 2010 15:54:32 +1300 Gregory Machin wrote:
> Hi Andrey.
> Thanks for you input.
>
> OK .. but most of those hosts should not be accepting email
> connections, buy my understanding. Or is it implied that email
> destined for that host would be handled by the email serv
In article ,
Sten Carlsen wrote:
> To me it looks redundant, "named-compilezone -o - zone file" should show
> you how bind interprets these.
> My guess is that they will be listed only once in the output.
I suggest you try it, and you'll see that you guessed wrong.
>
> I don't see how they co
They prevent people who start a potentially rogue mailserver to receive mails.
I.e. You centralize mails and make sure only your authorized mailserver
receives them when you dont have full control over these boxes.
-mat
On Oct 28, 2010, at 8:48 AM, Sten Carlsen wrote:
> To me it looks redunda
Hello Sten,
Thu, 28 Oct 2010 02:48:36 +0200 Sten Carlsen wrote:
> To me it looks redundant, "named-compilezone -o - zone file" should
> show you how bind interprets these.
> My guess is that they will be listed only once in the output.
>
> I don't see how they could belong to each subdomain, to
To me it looks redundant, "named-compilezone -o - zone file" should show
you how bind interprets these.
My guess is that they will be listed only once in the output.
I don't see how they could belong to each subdomain, to do that there
should be a"@..." to set a new origin?
On 28/10/10 2:14, Ia
Hi Gregory,
>mail02 IN A 192.168.xx.xx
> IN MX 10 mcvpemr01
> IN MX 10 mcvpemr02
>nelson IN A 202.xx.xx.1
> IN MX 10 mcvpemr01
> IN MX 10
Hello Gregory,
Thu, 28 Oct 2010 13:04:58 +1300 Gregory Machin wrote:
> Hi.
> I have taken over some dns servers, and the process of doing upgrade,
> half way through the process..
>
> I have a question about the zone files , as there is some
> configuration here that I have not seen before and
Hi.
I have taken over some dns servers, and the process of doing upgrade,
half way through the process..
I have a question about the zone files , as there is some
configuration here that I have not seen before and seems out of place.
here is an excerpt of the zone file
$TTL 14400
@
22 matches
Mail list logo