On Apr 30, 2008, at 1:00 PM, Al Iverson wrote:
On 4/30/08, Steve Atkins <steve(_at_)blighty(_dot_)com> wrote:
The NXDOMAIN thing means only one thing for a receiver. Don't
accept mail that claims to be from non-existent domains.
The reason there's discussion about it is that one of the ways
in which ADSP is iffy is that it only doesn't allow you to state
"I don't send unsigned mail from any hostname that ends
in .example.com". If your domain is example.com, and I
decide to send mail claiming to be from
mail.flooble.example.com there's no way you can publish
an ADSP record to assert that that mail isn't from you, unless
you guess the magic word "flooble".
You, of course, don't care because you know there's no
hostname or MX record for mail.flooble.example.com, so
no right-thinking recipient will consider it legitimate mail
anyway.
Thanks, that's what I thought, I think.
What if the from is a subdomain that isn't being used for mail, but
commonly exists. Let's say I set up DKIM+ADSP for spamresource.com and
mail.spamresource.com. Without any sort of tree walking, if I forget
to configure ADSP for www.spamresource.com, this could potentially get
through as "doesn't have DKIM but the domain is legit." Isn't this a
potential loophole that is resolved only by a very careful vetting of
everything in your domain tree and ensuring each hostname/zone is
configured with ADSP? Or am I wrong on that?
Exactly right.
It seems like the treewalking would help to address stuff like
this....?
Not in general. It will help only in the case where there are only one
level of hostnames below the top level domain. It won't help in
the cases where that's deeper.
People whose work environments consist solely of three level
hostnames see it as a magic bullet. Those who don't, see it as
a hack that adds complexity for recipients without buying the
senders any functionality they didn't already have via less
intrusive methods.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html