Re: 9 reasons for dynamic authorization records

On 2004-02-13, at 20.01, Hadmut Danisch wrote:

> On Fri, Feb 13, 2004 at 04:37:44PM +0100, Patrik Fältström wrote:
>>
>> (a) What is the problem with updating the zonefile every second? I
>> don't see any problems at all with it. If you said 100 times a second,
>> sure, then we can talk about potential issues, but once?
>
> Is that something we would really like to support? It would
> at least break normal DNS servers used as secondaries.

You use terms like "normal" etc in a way which I don't agree with help 
the discussion.

My point was that dynamic updates up to the order of once a second 
works, and the rest is an implementation issue. For example, to support 
this I would run a DNS server which can handle IXFR, or have very small 
zones. For example one zone per "customer". The number of updates per 
zone would then be minimized.

I have for my own computer a zone with only one record (zx81.paf.se) 
just to make ddns easier.

> Of course, you could write special DNS servers, which do that.

You don't have to.

> You're objecting my proposal about dynamicly generating authorization
> records with a proposal to update the zone table every second
> (and consequently leave the SOA expiry and TTL short).

No, I objected to your text which claimed it was not possible to do 
with DNS.

> But If you agree that authorization records are to be updated
> dynamically or within short time intervals, why do you want to
> modify or reinvent DNS and replace DNS servers if there is
> the better solution with HTTP servers and CGI scripts which
> doesn't need any protocol or implementation to be raped
> and which is already there, widely implemented, ready to
> be used and mastered by many sysops?

My point was that even if you have to update the records every second 
in a zone, you can do that with DNS, as you used this as one of the 
main arguments for your protocol and against the DNS.

>> (b) You seem to think, or I have missed something, that the end user 
>> is
>> sending things directly from wherever they are on the network?
>
> At least I know many users who do so and I received many complaints
> about RMX from users who felt handicapped because the first version
> of RMX did not explicetely support this.

This is one of the main things which "the community" does not agree 
about, how email is to move in the network.

 From my point of view, mail is _always_ flowing from a client to an 
outgoing MTA. Then from there using MX records to an incoming MTA which 
stores mail in a local storage. This is the simple form. Any mechanism 
which is to be developed at this point in time is a tool which the 
incoming MTA use to make a decision whether he is to accept the mail 
from the outgoing MTA.

What people argue about is whether the outgoing MTA can move around, 
like sitting on the same laptop as the client, and potentially get a 
new IP address quite often.

My answer to this is "this is up to the policy of the sending domain", 
but of course the system have to support something like this, if really 
needed.

The primary design (from my point of view, once again) is that the 
location of the outgoing MTA is decided by the responsible party for 
the sending domain, and not something the end user can decide.

Further, most people I have talked with which want to be able to "use 
MX records directly" are people which are at least "semi-geeks" which 
know how to run sendmail on their laptop _and_ they control the domains 
they send mail from.

These people should be able to run ddns for their laptop, and at the 
same time ddns for the email policy which approve sending of mail from 
the IP address they happen to have.

Now, there is a 2nd category, and that is a "semi-clueless" person 
which happen to have an IP address from an ISP which want their 
customers to use their outgoing SMTP relay regardless of what sending 
domain the user uses.

This 2nd example is from my point of view a _bad_ design of flows of 
email, because it forces the end user to send mail according to the 
network topology and not the topology the email system uses.

So, this is for me _not_ an argument for design mechanisms in the 
authentication protocol.

Summary: A mail which is sent is always to pass a "home outgoing SMTP 
relay", and the location of it is decided by the administrator of the 
domain.

If we don't agree on that, we are further apart than what I hoped. And, 
with "we" I don't mean explicitly you and me Hadmut, but the people on 
this mailing list.

> So your statement is pure nonsense. This is not about
> "my very very special network design which I use for this and other
> arguments".
>
> You would do much better to use objective arguments instead
> of attacking people personally and trying to ridicule their
> proposals.

I apologize for the words I used when I wrote my mail. I hope you 
accept the apology.

What I wanted to say was that what you have heard is not according to 
what I have heard.

But, you might as well as I remember when it was discussed whether 
"open relays for SMTP" is a good thing or not that many people said "we 
must have them". At the end of the day we see one of the things people 
seems to agree on _now_ is that open relays should not exist.

I have asked myself several times whether this request to get a 
protocol which make it possible to use MX directly from the laptop and 
not do (for example) DNS updates before they send mail is something we 
just have to say "no, this will not be possible to implement" to.

I am just asking.

> Try to be less biased.

I will do my best.

     Regards, Patrik