"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (James Antill) writes:
>
> >"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
>
> >> % telnet mail.bar.org smtp
> >> 220 mail.foo.org ESMTP ready
> >>
> >>
> >> This kills loop detection. Yes, it
[EMAIL PROTECTED] (Kai Henningsen) writes:
>[EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in
><968mjv$l9t$[EMAIL PROTECTED]>:
>> [EMAIL PROTECTED] (Jan Gyselinck) writes:
>>
>> >There's not really something wrong with MX's pointing to CNAME's. It's
>> >just that some mailser
[EMAIL PROTECTED] (James Antill) writes:
>"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
>> % telnet mail.bar.org smtp
>> 220 mail.foo.org ESMTP ready
>>
>>
>> This kills loop detection. Yes, it is done this way =%-) and it breaks
>> if done wrong.
> This is humour, y
[EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in
<968mjv$l9t$[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (Jan Gyselinck) writes:
>
> >There's not really something wrong with MX's pointing to CNAME's. It's
> >just that some mailservers could (can?) not handle this. So if you want
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (H. Peter Anvin) writes:
>
> >> In other words, you do a lookup, you start with a primary lookup
> >> and then possibly a second lookup to resolve an MX or CNAME. It's only
> >> the MX that points to a CNAME tha
[EMAIL PROTECTED] (H. Peter Anvin) writes:
>> In other words, you do a lookup, you start with a primary lookup
>> and then possibly a second lookup to resolve an MX or CNAME. It's only
>> the MX that points to a CNAME that results in yet another lookup. An
>> MX pointing to a CNAME is a
[EMAIL PROTECTED] (Jan Gyselinck) writes:
>There's not really something wrong with MX's pointing to CNAME's. It's just that
>some mailservers could (can?) not handle this. So if you want to be able to receive
>mail from all kinds of mailservers, don't use CNAME's for MX's.
No. It breaks a ba
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Gerhard Mack <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Thanklfully bind 9 barfs if you even try this sort of thing.
> >
>
> Personally I find it puzzling what's
On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote:
> Michael H. Warfield <[EMAIL PROTECTED]> wrote:
> > But, wait a minute. CNAME -> CNAME is a "must not".
> Cite the RFC please. 1034 says
> # Domain names in RRs which point at another name should always point at
> # the primary
Michael H. Warfield <[EMAIL PROTECTED]> wrote:
> But, wait a minute. CNAME -> CNAME is a "must not".
Cite the RFC please. 1034 says
# Domain names in RRs which point at another name should always point at
# the primary name and not the alias.
and
# domain software should not fail when pr
On Thu, Feb 08, 2001, Michael H. Warfield <[EMAIL PROTECTED]> wrote:
> But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME
> is a "should not". The "should not" leaves it to be implimentation
> dependent and not an outright ban. Sooo...
Actually, I had this conversation rece
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote:
> "Michael H. Warfield" wrote:
> >
> > > Please explain how there is any different between an CNAME or MX pointing
> > > to an A record in a different SOA versus an MX pointing to a CNAME
> > > pointing to an A record where at least
"Michael H. Warfield" wrote:
>
> > Please explain how there is any different between an CNAME or MX pointing
> > to an A record in a different SOA versus an MX pointing to a CNAME
> > pointing to an A record where at least one pair is local (same SOA).
>
> Ah! But now you are placing co
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote:
> > > Wouldn't that be true for any CNAME anyway?
> > That's the point...
> > In other words, you do a lookup, you start with a primary lookup
> > and then possibly a second lookup to resolve an MX or CNAME. It's o
>
> > Wouldn't that be true for any CNAME anyway?
>
> That's the point...
>
> In other words, you do a lookup, you start with a primary lookup
> and then possibly a second lookup to resolve an MX or CNAME. It's only
> the MX that points to a CNAME that results in yet another lo
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote:
> "Michael H. Warfield" wrote:
> >
> > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> > > Followup to: <[EMAIL PROTECTED]>
> > > By author:Gerhard Mack <[EMAIL PROTECTED]>
> > > In newsgroup: linux.dev.kernel
"Michael H. Warfield" wrote:
>
> On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> > Followup to: <[EMAIL PROTECTED]>
> > By author:Gerhard Mack <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > Thanklfully bind 9 barfs if you even try this sort of thing.
> >
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Gerhard Mack <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Thanklfully bind 9 barfs if you even try this sort of thing.
> >
> Personally I find it puzzling what's wr
Followup to: <[EMAIL PROTECTED]>
By author:Gerhard Mack <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Thanklfully bind 9 barfs if you even try this sort of thing.
>
Personally I find it puzzling what's wrong with MX -> CNAME at all; it
seems like a useful setup without the pitfalls
Thanklfully bind 9 barfs if you even try this sort of thing.
Gerhard
On Thu, 8 Feb 2001, Henning P. Schmiedehausen wrote:
> [EMAIL PROTECTED] (Matti Aarnio) writes:
>
> >NSes and MXes must ALWAYS point to NAMEs with A//A6 records for
> >them, specifically those names MUST NOT be CN
[EMAIL PROTECTED] (Matti Aarnio) writes:
>NSes and MXes must ALWAYS point to NAMEs with A//A6 records for
>them, specifically those names MUST NOT be CNAMEs. With NSes the
NS: must not
MX: should not
...stickler for details. ;-)
Henning
--
Dipl.-Inf. (Univ.) Henn
Hello Matti ,
On Thu, 8 Feb 2001, Matti Aarnio wrote:
...snip...
> Answer to the self-education question above:
>
> The NAME fields in usual BIND systems get appended the current $ORIGIN
> string value when the data in the field does not end with a dot:
>
> Wrong: IN MX 10 11
22 matches
Mail list logo
