Hallam-Baker, Phillip wrote:
But here, you assume that the RFC2822 identities would be the logical
next target. I'd think that the spammers would be more
likely to take a
less subtle approach and try to subvert the authorization
mechanism. In
the case of several approaches, this would mean DNS
poisoning, denial of
service attacks against nameservers, and other such trickery.
I think that the attacks you propose are brittle, entirely infeasible
on a bulk basis even if the attackers had the ability.
Forging RFC822 is trivial.
How aout we compromise here?
Put all the parts of the draft I suggest be non-normative off
in a separate document. Focus on defining the normative text
and getting that approved.
The non-normative text is delivered when nits are ironed out.
It would be informational so updates are much easier.
There is the issue of what you put inside the record itself. If it is
just the IP addresses and nothing more, than we can do this. However, if
we want to indicate other stuff in it like identity to verify against
(which I personally would like to be normative rather than a hint), then
it makes things a bit more complicated. If this is evolved into a very
generic policy mechanism, then we would open a can of worms.
I also believe that there is a difference of approaches here - some
people want to approach this with a single identity in mind. Others want
ability to choose different identities and mechanisms like SPF does. Yet
others, want ability to extend this into a more generic "server
configuration description" language. Determination of scope would be
helpful.
Yakov