On Sun, 2004-02-08 at 22:47, David Brodbeck wrote:
I'm not clear on why this isn't an issue. Let's say I get mail that
claims to be from ziggy.glyphic.com. If I do a lookup on that machine,
but don't step up to the parent domain, I don't have an SPF record to
judge the validity of the message by. Maybe I'm just unclear on the
concept, or missing something really obvious here.
--Mark Shewmaker <mark(_at_)primefactor(_dot_)com> wrote:
If ziggy.glyphic.com doesn't resolve at all, then most MTAs would reject
emails with a mail from from there on that basis alone, before any spf
tests, so the lack of an spf record would be a non-issue.
If ziggy.glyphic.com it does resolve because of DNS wildcarding, then
presumably the *.glyphic.com domain owners would also have wildcarded
spf records as well.
I'm in agreement with Mark. Also, I think there are really good reasons to
NOT allow SPF checks to be done on higher-level domains. It makes sense to
most people that corp.domain.com should be a logical part of domain.com,
but that daemon.co.uk is not the same entity as co.uk. (Yes some top-level
domains have A records, try http://cc/ and http://tv/ :) So, you cannot
logically/predictably tell where one domain should be governed by the same
policy as its parent... it should be explicitly verboten.
Unfortunately this means all A records also need SPF records. I wonder if
something like this could give the proper result:
@ IN A 10.2.3.4
@ IN TXT "v=spf1 a mx -all"
* IN TXT "v=spf1 -all"
www IN A 10.2.3.4
support IN A 10.2.3.5
support IN TXT "v=spf1 a mx -all"
In a case like this would "www" have an A but no TXT, or would a lookup on
www (TXT) give you the wildcard?
Interesting. Anyway it's probably safer to SPF anything that has either MX
or A including *
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>