On Jun 4, 2007, at 6:34 PM, Stephen Farrell wrote:
Douglas Otis wrote:
It is not clear why a "no mail sent" assertion must be excluded
from a policy statement.
Well... because that was the concensus. Feel free to re-read the
archive, but basically: End of story.
Consensus does not necessarily produce a solution that improves
security.
Making assertions of "no mail from a domain" remains an important
aspect for protecting higher overheads in a DKIM process. This
assertion efficiently deals with spoofed messages. Relegating this
policy to SPF underlines a glaring lack of consideration given security!
Reactions regarding use of wildcards from DSN WGs have been
predominately "Don't do it." Limitations regarding new RRs are due
to a corporate environment established as an integrated solution for
a commonly desktop solution. Even overcoming this barrier will still
confront dangers associated with wildcard abuse.
Unlike other DNS records, wildcards can cause an infinite amount of
uncached traffic, that while being cached, is not resolved from
cache. Often wildcards are utilized by bad actors to deploy random
labels which happen to be more difficult to filter. Otherwise
innocent wildcards can also be exploited a component in some DDoS
attack as well.
Over the last few years, spammers have become more malevolent and
organized. Their skills can be measured by the growth and nature of
their networks. Malware and spam go hand in hand where SPF gives
this population an effective tool for poisoning DNS or staging a DDoS
attacks. Unfortunately, wildcard records also becoming less safe as
a result of this growing population.
The safe answer would be to require an MX record before accepting a
message, and publish policy at this location. As an interim
solution, also publish policy at the location of other A records as
well. The XPTR or any other wildcard scheme will require that these
records be placed at each and every node within a domain! How can
that be safe or sane?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html