dotis at mail-abuse.org
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
> 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
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
- policy records must also be wildcards published at every existing
- 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.
More information about the NANOG