Re: [Asrg] Re: RMX evaluation

On Thu, May 08, 2003 at 05:47:00PM +0000, Paul Vixie wrote:
>                             Repudiating MAIL FROM
> 
>    Status of this Memo

This is in principle the same approach as RMX, but a different
implementation. (i.e. it lists the IP addresses of machines
authorized to deliver in DNS, it differs in the way those addresses
are stored).

It is very astonishing that it is Vernon who brings that proposal.
Concerning Vernon's objections against RMX, there is no difference
between RMX and this proposal. So why should those objections 
apply on RMX, but not on that proposal? The effect that use of 
a certain domain as a sender address will be limited to some
IP addresses as well. It will require DNS queries as well. 
It will require hotmail, yahoo, aol users to deliver through
the hotmail/yahoo/aol relays as well. So what's the point in 
quoting that proposal in context of the objections against RMX?

The advantage of Paul Vixie's proposal is, that it doesn't require
a new DNS RR type. 

The disadvantage is, that it is error prone and takes a high overhead:

There are providers who provide services for 20..2,000,000 domains. 
Since in this proposal the domain zone tables must list every single
mail relay, all zone tables must be updated if the provider installs
an additional relay. If the provider does have access to the zone
tables, this is just a heap of work. If the provider does not have
access to the zone tables, then it is a severe overhead and delay
to inform all the domain owners and ask them to update their tables.
When writing your domain table, you need a detailed list of the 
relays your provider has. At least you need to know the number of
relays. In reality, it would certainly look like this:

.. MX  relay0.provider.com
       relay1.provider.com
       relay2.provider.com

But you will always have to update the list if the provider uses
one more relay than you have listed. 

That's why RMX uses an indirection step through the provider's 
APL records. It's a design criterion to avoid this overhead and
delay.

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