[ietf-dkim] protecting domains that don't exist
dotis at mail-abuse.org
Wed Apr 16 16:30:19 PDT 2008
On Apr 15, 2008, at 7:33 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>> This is still assuming use of DNS in conjunction with some future
> Yes, ADSP is published using DNS, and it's about "mail", the
> abstract says. ADSP flags in Fido nodelists for the purposes of
> Fidomail is not discussed in RFC 5016 (sorry, couldn't resist after
> you forced me to figure out what "PNRP" is ;-)
>> It seems using DNS to assert policy necessitates use of DNS by all
>> possible transports.
> When I mentioned missing domain literals I meant it, but in essence,
> yes, the format of mail addresses in 2822upd is for DNS lookup, not
> for Fido, UUCP, or X.500.
Since it is impossible for domain literals to represent a signing
domain for DKIM, it would seem obvious literal addressing is a matter
not covered by ADSP.
RFC2822 specifies "Internet Domain". While the term Internet Domain
infers a single name space, name spaces within corresponding services
resolving addresses and services could be introduced under differing
TLDs. PRNP was given as an example, since this scheme resolves
address structures needed to navigate through gateways and tunnels.
While this scheme is proprietary, existence of an enhanced name
service represents a current need being fulfilled. PRNP allows groups
to assign "friendly names" with unique identifiers which may overlap
DNS name space. Even so, this name space could be defined in a
complaint manner using a scheme like name._group for example. With
ADSP imposing "existence" requirements, now only DNS determines what
is an Internet Domain.
>> Unless consensus surrounding ADSP being forever linked to SMTP/DNS
>> can be established, an assumption of 'existence' checks seems
>> rather dubious.
> DKIM isn't bound to SMTP, and existence checks for something that's
> no domain might not need DNS. But the discussed ADSP draft wants us
> to look up _adsp._domainkey.example. in DNS if example. exists in
> DNS (swapping steps 1 and 2).
Agreed, DKIM is not bound to SMTP. The suggestion is to avoid
conflicts by binding ADSP policy assertions specifically to email
addresses _suitable_ for SMTP/DNS. The current ADSP draft requires
RFC2822 Internet Domains "exist" within DNS, which is not currently
required. ADSP stipulates DNS. ADSP is to benefit SMTP.
> Let's solve problems with completely different technologies later,
> and after we've seen that ADSP makes sense for email, that will take
> more than a year.
Agreed. So limit the scope of the policy assertion to just SMTP/DNS.
Consensus should be reached about what ADSP "existence" requirements
>> The NXDOMAIN existence check also ignores issues related wildcards
> There are no wildcard issues I'm aware of. Nothing outside of a
> zone, neither below nor above it, can create wildcards affecting the
> zone. Please correct me if that's wrong, and give an example of
> what you have in mind...
When the ADSP existence scheme depends upon an NXDOMAIN, this will
fail to offer protections when either a network or TLD provider
introduces wildcards, or when the domain itself uses wildcards. By
depending upon NXDOMAIN, ADSP protections just not possible when
wildcards are introduced.
>> It is rather ironic a well considered alternative policy scheme
>> depended upon use of wildcards and publishing records at every node
>> blocking the wildcard.
> ...dunno what you mean. A single existing node blocks any wildcard
> above it for the complete subtree where it is the root, doesn't
> it ? If you are interested in domain.example. make sure that it has
> an A or MX or whatever, and there is no wildcard that could affect
> anything below domain.example.
> Skipping your 2821bis rant, I supported you as good as I could, when
> Keith gave up the battle was lost from my POV.
Perhaps pride inhibits an ability to impose necessary discipline,
similar to a proud parent ignoring their misbehaving child. It is
ludicrous to suggest domains publish bogus MX records to avoid
undesired SMTP traffic, but those implementing SMTP can not be
expected to publish valid MX records. This is shameful.
More information about the ietf-dkim