In <a06020418bcf3b87031e9(_at_)[192(_dot_)136(_dot_)136(_dot_)83]> Edward Lewis
<edlewis(_at_)arin(_dot_)net> writes:
At 14:56 -0500 6/14/04, wayne wrote:
In that case, why not just rely on the DNS RR set, putting multiple
RR's in the same location? You'd have to define how to
reassemble/combine them.
Because what makes the records "too large" is that they no longer fit
in a 512B UDP packet. Putting them in a RR set won't help. Falling
back to TCP is more expensive than several UDP DNS lookups due to the
three-way TCP handshake setup and the four-way TCP teardown.
In section 4.8, you mention "A" lookup. Is AAAA explicitly not done
in that case?
Sorry, I didn't check that reference.
Yes, the exists: mechanism explicitly checks *only* A records, even if
the MTA connection is via IPv6. This is to maintain compatibility
with already existing DNS blacklists and whitelists.
While looking at that I noticed I marked up 4.6 (but didn't dog ear
it). It says "Check all validated hostnames ... If any do ..."
Instead of checking all, why not check until one is found that
satisfies the condition?
I'm not sure why Meng phrased this section the way he did, but you can
certainly short-circuit the evaluation.
The problem is with using malicoius SPF record such as:
v=spf1 a:%{t}.victim.com a:%{t}.victim.com a:%{t}.victim.com ..."
Such a SPF record could be used for DoS attacks. There is no good
reason to use the timestamp as part of an SPF mechanism, and if each
evaluation of %{t} is different, it will create a different DNS
lookup.
I see. I guess I never say anything that explained the "t" other than
the definition as equaling the current time stamp and then the warning
about it's impact on DNS. Maybe it would be clear to show an example
or explain a "positive" use for the macro.
Personally, I'm not that attached to the %{t} macro variable, so maybe
I'm underselling it.
The idea is that it would be used in conjunction with the exp=
(explanation) modifier. While the (macro expanded) explanation text
can be anything, typically it is a URL that someone who had their
email rejected can go to for a more complete explanation. The
timestamp can be added as an argument to the cgi-script, along with
the IP address, the email address that was used, etc. The timestamp
could then be used to narrow down the exact email that was sent, or to
format it in a localized format, or whatever.
The %{t} macro variable is an example of something that I think could
be gotten rid of from SPF without any problems, but then, it also is
trivial to implement.
-wayne