Some more comments.
1)Just a note as to why this discussion is important:
It is very relevant to the current agenda item:
- Due 2004-07-02: Decide if CSV is complimentary, parts to be
incorporated, or dropped.
Does CSV's greater DDoS resistance matter a lot? Or not?
2)On 6/28/04 5:56 PM, Hallam-Baker, Phillip sent forth electrons to convey:
Caller-Id required a single packet in each direction for the vas[t]
majority of mail interactions.
Do you see why I feld that this statement was incorrect, at least?
Well, we have a decision to make by 7/2, and currently, macros are in
the spec and likely to stay, so our decision should be based on that.
Please read the earlier post to this thread at
<>I don't see you addressing the concerns Doug raised.
... Does it work in the face of
malicious macro SPF records?
Only if we decide to support the macro interface. I was hoping that
we would reject it on the grounds that all the use cases that have
been stated can be implemented anyway.
I'm confident that, without such limits, SPF is likely to be turned off
due to attacks on users.
I'm saying that we need to explore further whether with limits high
enough to allow necessary functionality, it can survive such attacks.
If what you are trying to say is that there must be some limit to the
complexity of a query I think that is correct, clearly it is a bad
thing if records branch out indefinitely.
I asked before if you were arguing that all mail servers should rely on
local caching DNS servers that will cache all the word's active LMAP
I'm not trying to deep 6 SPF. I'm trying to make it stronger and better
by attacking its weaknesses virtually, while they are readily fixable.
Note, I recently expressed my support Unified SPF (which incorporates a
BTW, I was surprised that the -01 SenderID drafts that came out didn't
have any Unified SPF stuff in 'em. I interpreted something Meng said to
mean that I should expect to see it in a draft soon, so I'm still