Re: [Asrg] Assume perfect knowledge by domain registry provisioners, so what?

[David Walker <antispam@grax.com>]

Well I hate to use this as an argument in favor of RMX but it is true (at 
least theoretically).

Assuming a wide implementation of RMX by DNS admins ticked that their domains 
were used as return addresses on spams, the spammers would have to register 
their own junk domains.  If mail admins started rejecting mail from these 
junk domains the spammers would have to register more junk domains.  More 
domains registered = more profit for a domain name registry operator.


On Thursday 08 May 2003 06:36 pm, Eric Brunner-Williams in Portland Maine 
wrote:
> The discussion of RMX prompts me to ask a question.
>
> Why should domain name registry operators and their registrars "care" about
> this problem, and assuming they did "care", what could they know that would
> be in their interests to know?
>
> I ask this as a contributor to a domain name registry provisioning
> protocol, a prior registry operator (gTLD and ccTLD) and registrar
> (current, voting), as well as a minor ISP operator.
>
> For reasons others have said sufficiently, and because I have thought about
> an equivlant mechanism for a problem I once thought similar, I don't think
> RMX is useful in this problem domain.
>
> That said, I want to know if, assuming perfect knowledge in the universe of
> dns provisioners (not publishers, that is seperate question), any actor(s)
> in that universe could do anything that would have a first-order effect on
> the present spam problem.
>
> RMX advocates should have a story I can relate to the ICANN Registrars
> Constituency meeting in Montreal next month.
>
> Eric
>
> Ob.Tech.: I've proposed making EPP peer-to-peer (beep transport mapping),
> with a registrar-initiated session-establishment restriction removed, and
> registry-initiated state-push, solving the escrow and trans-registry sets
> of problems, and I'm mildly curious if there is a serious use case for any
> parts of this arise from an ability to be causal in technical solutions to
> spam.
> _______________________________________________
> Asrg mailing list
> Asrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg