The target us a hostname (RFC 1035).
3.3.9. MX RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE/
/
In message , Tony F
inch writes:
>
> John C Klensin wrote:
> >
> > If a particular SMTP implementation is aware of and follows the spec,
> > almost any consensus indicator that doesn't conflict with other things
> > should be fine --
>
> There are actually more constraints than you imply in you
(Warning to DNSOP and IESG -- this response is going to descend
quickly into SMTP esoterica and is probably safe to ignore from
a DNS perspective)
--On Friday, July 18, 2014 22:39 +0100 Tony Finch
wrote:
> John C Klensin wrote:
>
>> > MX target names should obey the LDH host name rules.
>>
>>
John C Klensin wrote:
> To the contrary, I think the problem here (if there is one) is
> that these types of ideas are being invented, specified through
> formal or informal private discussions, deployed, and then
> brought to the IETF for standardization.
The null MX record is simply re-using t
John C Klensin wrote:
> > MX target names should obey the LDH host name rules.
>
> I completely agree, but SMTP imposes no such requirement.
RFC 974 specifies that the target of an MX record is a host name.
> > You won't be able to enter [***] into many DNS admin tools since
> > they enforc
--On Friday, July 18, 2014 20:39 +0100 Tony Finch
wrote:
> John C Klensin wrote:
>>
>> If a particular SMTP implementation is aware of and follows
>> the spec, almost any consensus indicator that doesn't
>> conflict with other things should be fine --
>
> There are actually more constraints
--On Friday, July 18, 2014 14:59 -0400 John R Levine
wrote:
>> Today's problem, IMO, is that, while there is little debate
>> about "DNS-based solution", or even "DNS-based solution
>> involving something special in the relevant MX record", I
>> haven't seen a careful analysis by DNS experts on
John C Klensin wrote:
>
> If a particular SMTP implementation is aware of and follows the spec,
> almost any consensus indicator that doesn't conflict with other things
> should be fine --
There are actually more constraints than you imply in your message.
> "."
Has the advantage of being imple
Today's problem, IMO, is that, while there is little debate
about "DNS-based solution", or even "DNS-based solution
involving something special in the relevant MX record", I
haven't seen a careful analysis by DNS experts on which of
several DNS approaches have the least bad operational
properties.
(copying John Levine given his recent summary on the IETF list
as well as his co-author role)
--On Friday, July 18, 2014 10:36 -0400 Olafur Gudmundsson
wrote:
>> If this is a worry for the root server operators (but I
>> thought they had said in the past that it doesn't pose a
>> problem) then t
Dear colleagues,
I've had a look at draft-ietf-dnsop-dnssec-key-timing-04. I have no
objections to the alterations to the document, and I say again what
I've been saying for, I think, two years now (maybe more): giving
useful advice, even if not perfect, on this topic will be more helpful
than pr
> I think it would be great to have this document use ?no-mail.invalid.? as the
> domain name rather
> than ?.? in the MX record i.e.
> foo.bar.example MX 0 no-mail.invalid.
>
> But this is just a question of preference and installed base.
The aspirations of this document were far more
Olafur Gudmundsson wrote:
>
> I think it would be great to have this document use “no-mail.invalid.”
> as the domain name rather than “.” in the MX record
I don't think this would help. It would be different from what existing
code recognizes and it would not divert the unwanted A+ queries aw
On Jul 18, 2014, at 10:52 AM, John Levine wrote:
>> Many years ago Joe Abley and I suggested to create a special name for
>> exactly this purpose
>> a name that was guaranteed to never exist in the DNS thus the first lookup
>> would always return NXDOMAIN thus the A+ lookups would never ta
> Nico Williams wrote:
> >
> > I think what you're objecting to is the section 4.3 and related text
> > that conflates "does not accept e-mail" with "does not send e-mail".
> Section 4.3 describes what is already done by existing implementations of
> this spec.
> Exim in its default configuratio
>Many years ago Joe Abley and I suggested to create a special name for exactly
>this purpose
>a name that was guaranteed to never exist in the DNS thus the first lookup
>would always return NXDOMAIN thus the A+ lookups would never take place.
>http://tools.ietf.org/html/draft-jabley-sink-arp
On Jul 18, 2014, at 10:18 AM, Tony Finch wrote:
> Paul Vixie wrote:
>>
>> what's unstated here is that every SMTP sender who encounters such an MX
>> without understanding its new meaning will do two or three lookups: ".
>> MX",
>
> No, MTAs do not look up MX records for MX targets.
>
>> [".
Paul Vixie wrote:
>
> what's unstated here is that every SMTP sender who encounters such an MX
> without understanding its new meaning will do two or three lookups: ".
> MX",
No, MTAs do not look up MX records for MX targets.
> [". ",] and ". A".
But they might do these lookups, yes.
If th
--On Friday, July 18, 2014 06:46 -0700 Paul Vixie
wrote:
>...
>> There are no addresses associated with the root, so the mail
>> server will immediately report a delivery error. RFC 5321
>> section 5.1 paragraph 2 final sentence.
>>
>> The SMTP server will not try to connect to the root name
>>
--On Friday, July 18, 2014 23:18 +1000 Mark Andrews
wrote:
>> At least in the near term, some SMTP Server ("MTA")
>> implementations will conform to that rule (many already use
>> it) and some won't. For the latter, they will presumably do
>> what the SMTP specs say to do. In summary, that i
Tony Finch wrote:
> John C Klensin wrote:
>> IN MX 0 .
>>
>> At least in the near term, some SMTP Server ("MTA")
>> implementations will conform to that rule (many already use it)
>> and some won't. For the latter, they will presumably do what
>> the SMTP specs say to do. In summary, that
John C Klensin wrote:
>
> IN MX 0 .
>
> At least in the near term, some SMTP Server ("MTA")
> implementations will conform to that rule (many already use it)
> and some won't. For the latter, they will presumably do what
> the SMTP specs say to do. In summary, that is to look up the
> addre
In message <93f32648fd67ae6abac47...@jck-hp8200.jck.com>, John C Klensin writes
:
> Hi.
>
> I have a few questions that I don't want to clutter the IETF
> list about but about which I would hope DNS experts, especially
> DNS root operations experts, would step in if they have
> opinions. IESG co
Hi.
I have a few questions that I don't want to clutter the IETF
list about but about which I would hope DNS experts, especially
DNS root operations experts, would step in if they have
opinions. IESG copied only for the record. I want to stress
that these are questions: I may know enough to ask
Nico Williams wrote:
>
> I think what you're objecting to is the section 4.3 and related text
> that conflates "does not accept e-mail" with "does not send e-mail".
Section 4.3 describes what is already done by existing implementations of
this spec.
Exim in its default configuration validates th
25 matches
Mail list logo
