dotis at mail-abuse.org
Wed Aug 15 16:33:55 UTC 2007
On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:
>> On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
>>> Since all valid email domains are required to have a working
>>> postmaster you can safely drop any email from such domains.
>> Use of root "." as a name for a target may create undesired non-
>> cached traffic when applications unaware of this convention then
>> attempt to resolve an address for servers named root.
> All modern iterative resolvers are required to support negative
Indeed, RFC 2308 changed negative caching support from optional for
any caching resolver. Those that have negative caching may
significantly truncate the duration. There are several websites
recommending negative caching be disabled to permit faster recovery
from intermittent negative answers. In other words, a negative
answer is less likely to have been cached. Use of root target names
will impact roots in cases where:
- an assumption of negative caching is wrong,
- for MX records where the root name convention is not in place.
With email, transaction rates are high and highly distributed which
tends to diminish negative caching protections.
>> The use of root as a convention will complicate a general strategy
>> identifying adoption of a protocol by publication of a discovery
>> record. The use of root as a target name in SRV records has been
>> problematic, although this convention was defined for SRV records
>> at the outset.
>> Using an MX record to mean "no email is accepted" by naming the
>> target 'root' changes the meaning of the MX record.
> Not really. It's entirely consistant with existing DNS usage
> where "." is a domain name / hostname place holder.
> Lots of RR types use "." to indicate non-existance.
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.
>> It is also not clear whether the root target would mean "no email
>> is sent" as well.
> That is, I'll agree, more of a issue but no one can reasonably
> expect people to accept non-repliable email.
That would have been made clear by simply requiring MX records for
>> A clearer and safer strategy would be to insist that anyone who
>> cares about their email delivery, publish a valid MX record.
>> Especially when the domain is that of a government agency dealing
>> with emergencies. At least FEMA now publishes an MX record. This
>> requirement should have been imposed long ago. : )
> I much prefer positive data vs the absence of data to make a
> decision. "MX 0 ." is a definitive response saying you don't want
Not having an SMTP server and no MX record provides a clear
indication of a policy "I don't want email." Policy will often
require a greater amount of information. To discovery policy must
the entire domain be queried? 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. In this case, one
cached SPF record may utilize a sequence of originating email-address
local-parts in a spam campaign to generate 10, 20 or perhaps 30 MX
record transactions per message. Each MX transaction might be given
a maximal label size as well. This attack would completely free for
spammers and would not expose their 0wned systems, as the attack will
emanate from the recipient's resolvers. Email logs may not offer
clues in how the attack happened, as victim domains might have been
obfuscated by a combination of local-part and SPF script. And yes,
SPF is another method some recommended for expressing email policy.
When can the recipient of a message know whether the originating
domain expressed policy that goes beyond NO? Query all TXT RR?
Examine policy at some policy location? The only place where policy
should published is at a protocol discovery record. In the case for
email, it would be at the MX record. Wildcards for policy will
likely create other problems.
The XPTR proposal by Phillip Hallam-Baker envisions such a wildcard
scheme where a new pointer record is to be published at _every_
A simpler scheme would be to require a protocol discovery record and
then expect any related policy be published adjacent to the discovery
record. For email, the MX record would be a protocol specific
More information about the NANOG