MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
Bill.Oxley at cox.com
Bill.Oxley at cox.com
Tue Jun 5 09:57:13 PDT 2007
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Douglas Otis
Sent: Tuesday, June 05, 2007 11:58 AM
To: Stephen Farrell
Cc: Scott Kitterman; ietf-dkim at mipassoc.org
Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
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
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?
NOTE WELL: This list operates according to
More information about the ietf-dkim