[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Input on identities



Markus Stumpf wrote:

On Wed, Apr 07, 2004 at 11:49:39AM -0500, Pete Resnick wrote:


Many sites don't own records in the reverse space for their IP addresses,


Then we should question why this is so and if it is needed or if it
can be handled by their ISP as well.
And we should also question why ISPs don't handle the revDNS any more.
And managing revDNS will probably be less work than to add LMAP type
records to all zones of all customers.


Here is the problem that virtual and co-hosting sites often face:

Virtual host virtual-1. com is hosted by ISP-I.com

The owner of virtual-1.com uses another system with a dynamic IP address
to manage their virtual-1.com domain hosted by ISP-DSL he calls 'home.virtual-1.com'
and he runs his own MTA on that system when online. How is ISP-DSL going
to do the reverse push of that domain name to the world in anything
close to real time? How can ISP-DSL verify that that user has
the right to belong to the virtual-1.com com domain?

How is co-hosting ISP-H going to know the names of the domains
and hosts that virtual-h.com is using? The ISP does not manage
those systems.

For ISP-H they could write a tool that allowed their co-hosting sites
to publish the required information to ISP-H that could then be
pushed to the reverse maps. But how could the ISP verify
that it was correct? How often would the ISP have to check
the records against the forward maps just to see if virtual-h.com
did the correct thing? Or forgot to update the records?

I do not think that forcing the reverse DNS records is manageable by ISPs.

but do own the forward domain records. I'd much rather see a situation in which everyone has the ability to publish information about which machines are expected to be MTAs or their domain instead


.....

IP based lists are very simple, as they tell "the owner of the IP space
thinks this IP hosts a MTA that should sending messages across the Internet".
What each validator does with that information is up to him.
If some ISPs don't handle revDNS for their customers then the market
will kill those ISPs or they will handle revDNS for their customers.

I do not think that most (all?) hosting sites will be able to comply to that
if it were a requirement.

The situation where IP based lists will not work is for MTAs on dynamic
address space. The question is whether we should encourage hosting
MTA on dynamic address space with regard to stability and the spam
problems we encountered over the last decade.

Many ISPs oversell their dial up account 100:1 or more to static IP addresses (Think $$ per IP).
I do not think they will ever care to increase their IP costs to 1:1 to each dial up customer
that has an MTA.

They could force their customers to use their ISPs MTA using dynamic IP.
However there are endless ways around that as seen by many cable customers
facing that problem. I have had a very hard time blocking music stealing software
for one of my customers as the server sites accept their connections on ALL ports.
The client code just needs to find any outgoing port. I think that forcing what
you suggest will just create new tools to rely email via port 80.

In Germany e.g. data
protections laws prohibit that ISPs store connection data for flat
rates as the data may only be stored for accounting purposes and with
a flat rate this is not needed.

My fear is that LMAP style authorization mainly helps big sites to
be protected from joe jobs, but joe-loser.org who doesn't even know what
an IP adress is will be helpless and spammers will shift from big mail
service providers to zillions of small domains without LMAP. The overall
win will be zero for a very long time.

Just one of many steps (as someone said recently).

--

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                              | Cell:   (208)520-4044

We Do Standards - You Need Standards


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature