Discovering policy

>> Yes, and this convention still generates nuisance root traffic
>> whenever the application fails to comprehend "." is a special
>> target. This is true even when _defined_ as a special target for
>> the specific resource record, as with SRV. In the case of an MX
>> record, there is _no_ such definition.
> So we write a RFC. That I though was implicit.

Do not depend upon applications not to resolve addresses for root
names, even when a convention is explicit. Depending upon root
answers to support a protocol feature unrelated to DNS is normally
considered a design mistake isn't it?

  No. The root must exist. To many things break when there
  is no root.

> If you have applications which don't honour SRV's "." processing
> rules report the bug.

Even Paul Vixie, the author, will likely agree the RFC has the "bug".

  No, it's the implementations that have the bug.

  If you want really scary "A" to indicate that you are
  offline but exist. This is actually using as it was
  intended. i.e. I exist but I do not know my address.

>> Not having an SMTP server and no MX record provides a clear
>> indication of a policy "I don't want email."
> Which requires a SMTP server to attempt the TCP connection. It
> also requires the SMTP server to re-try until it times out the
> messages which could be days.

Who would be motivated in making the change? Trying every address
record is unsuitable for today's email environment. Its time for a

  I suspect the SMTP vendors would pick it up reasonably quickly.

  I suspect everyone that uses "MX 0 nonexistant" today would
  pick it up.

  I suspect everyone has a SPF record indicating they don't
  send email would pick it up. They don't want the bounce

  It's usable by sites with idiotic resolver libraries that
  can't return unknown record types.

> SPF is optional. MX processing is NOT optional.

MX records should not optional, but they are.

  I said MX processing. You *have* to do the lookup.

> Most SMTP client will fail immediately if they get a positive
> indication that there are no address records for the MX. Fixing
> them not to ask the question is a optimisation.

Publishing wildcard MX root records everywhere represents a poor and
possibly hazardous solution.

>> Policy will often require a greater amount of information.
> This is a simple binary decision. I want email for this domain or
> not.

A policy may need to express whether the domain signs some or all of
their outbound messages. Not very binary is it?

>> To discovery policy must the entire domain be queried?
> You have the name. It has a address. You don't want email to be
> sent there. You add a single MX record next to the address. No
> seaching. Just direct query.

Policy is not normally published for inbound traffic. SMTP
extensions negotiate inbound policy requirements. However, policy
could be essential for outbound traffic. A domain name might be the
subject of phishing attacks. How policy is applied must ensure even
sub-domains are covered.

A safe strategy for applying an outbound message policy is to:

- check whether there is a discovery (MX) record

- no discovery record, refuse the message

  If there is a "MX 0 ." record, refuse the message

- check whether a policy record is adjacent to the discovery record

- no policy record, there is no policy

>> A wildcard MX record and root name convention exposes a domain to
>> an SPF script attack, where a different convention is expected for
>> no email.
> No the presence of the record with "." as the MX target would stop
> all further processing.

The SPF script processing is looking for address matches, which may
or may not include those within the MX record. SPF libraries might
not quit after hundreds of no answers. This behavior is just one of
the reasons these libraries are hazardous. Remember an outbound path
may not be the same as the inbound.

> You don't go to SPF processing as the source address is non repliable.

When the originating domain fails to offer a discovery record?
Section 5.1 of the updated version of 2821 allows A or AAAA when
there is no MX. This allowance must become obsolete and the process
ends when there is no MX record. This means one does not have to
wait for unmotivated domain owners to adopt the MX root strategy.
Instead, those wishing to have their email accepted have a powerful
motivation to publishing a valid MX record. At that point, much
sooner than for your scheme, no MX will then mean no acceptance or
will indicate where policy can be found.

  There are lots of people who have "MX 0 nonexistant" today
  for domains for which they don't want email. All of those
  break sanity checks for MX records. Have exactly one exception,
  "." is codable.

Your scheme now means that:
  - both the MX root records must be wildcards published at every
existing node
  - policy records must also be wildcards published at every existing
  - or the recipient must walk up the domain

  No. You don't need policy records if you treat "MX 0 ."
  as no email shall be sorced from this domain. You want to
  block email from sites with no MX records. "MX 0 ." is
  equivalent to having no MX records.

Your scheme will not scale, especially when replicated by other
protocols. This approach risks root and second level domains.
However, policy at the discovery record can scale and is much safer.

  What other protocols are unauthenticated PUSH transfers?
  Just about all the other protocols a pull transfers and / or