Discovering policy

Thu Aug 16 02:36:48 UTC 2007

On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote:

>> 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?

> 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".

>> 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  
change.

> SPF is optional.  MX processing is NOT optional.

MX records should not optional, but they are.

> 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

- 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.

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  
node
  - or the recipient must walk up the domain

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.

-Doug