I think that Meng's point was that detecting dialup/cable/DSL lines is
useful and Yakov's point is that trying to maintain a list of this type
through central admin is insanity.
I think both positions are reasonable and point to the same conclusion, it
would be good to have a means of publishing this information in a
hierarchical, top-down manner.
The one quibble I have here is again the semantic attempted. I think we
should think beyond email here and get away from the 'permissions' mindset.
If an ISP does not want a customer to send SMTP email they can do so with
ease, just block port 25 outbound.
This is the second time today that someone pointed me to lunacy comming from
the same sorce. I really don't think he means it but this seems to be a
'make sure the plebs don't have full internet connectivity' rant.
What the (reasonable) sysop did was to publish info that told people whether
a connection was static or dynamic. It would also be useful to know if a
connection was high speed or low speed.
From this people can draw their own conclusions as to whether they want to
accept mail from that source. But note that Meng suggested FIRST test for
SPF authentication and only bounce dialups that fail. I think this is
exactly right, any sender that provides acceptable authentication and
accreditation should always be accepted, regardless of whether they are
using a dedicated T1 or a hotel WiFi connection.
Hence my strong suggestion that we have DESCRIPTIONS in the reverse DNS not
a list of permissions. The description of the line config is likely to be
maintained accurately. The permissions are unlikely to be set the way I
would want as a receiver and I will inevitably end up reverse engineering
them to try to uncover the reason the permissions were set that way.
Descriptions are also much better when we look for other uses of the same
information. For example my anti-phishing work. Here we would like a quick
way to work out what kind of IP address we are dealling with - knowing of
course that the information we get from any source can be wrong or even
intentionally misleading. Another example of re-use of this info would be
for other protocols like IM and video conf which will face the same spam
issues.
What I would like to see is a record of the form:
1.0.0.10.in-addr.arpa RP "abuse(_at_)example(_dot_)com"
_profile.1.0.0.10.in-addr.arpa TXT "speed=16, dynamic
residential "
"notify=rp,_inws._http._tcp"
_inws._http._tcp.1.0.0.10.in-addr.arpa
SRV inws.example.com 80
This would mean:
The speed of the connection is 16 times 64Kb/sec, i.e. 1Mb/sec
The connection is allocated dynamically from a pool
The connection is allocated for residential use
The notification services supported are the DNS RP record and the web
service inws.
I think this meets all the needs that Yakov, Meng, the nanog complainer and
the users of the "Worthless Project" are seeking, and also the phishing
response teams such as ours.
To give you some context here, the biggest problem we currently face is
getting in touch with the responsible ISP when a phishing scam is underway.
This can take days if the information in the various registries is not
right. Reverse DNS is not perfect but there is a good chance it will work.
Phill