On Wed, Jan 26, 2005 at 09:26:04AM +1100, Mark Andrews wrote:
You are adding a prefix not a type. If you added a type there would be no issue. It would work with existing RFC 2317 sytle delegations.
The issue would be deployment. Design Choices When Expanding DNS (draft-iab-dns-choices-00.txt) While I agree with the proposal in principle that a new RR type would be the best choice (at least for a lot of situations) there are situations where a) deployment is way too slow (even with RFC 3597) DNS servers/stub resolvers/caches is one but not the only issue, management software is one of the many others b) it is not usable (just think SRV records and one would need a new RR type for every protocol/service) When we started with MTAMARK we thought about using Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. and using TXT labels "ASRG.MTA=yes" or "ASRG.MTA=1" "ASRG.MTA=no" or "ASRG.MTA=0" at the same level as the PTR records. This is without any problems as related to RFC 2317, however there may be collisions with other TXT records, if there are other TXT records you have to wade through them to find if there is one suitable and if there are others there is always the 512 bytes limit. Thus we were convinced to switch to a scheme with a precise question that should also be extensible, as reputation and publishing policies in the future will be an even more important issue as they are now.
No. I'm saying that by unnecessarily using a prefix for MTAMARK it is introducing complications.
We don't think the prefix is unnecessary, quite the contrary.
So you are not going to delegate /24s? Are you going to remove the existing /24 that have been delegated? They fact that customer needs a /24 doesn't magically make them compentant. I repeat size is no indictation of compentance.
The fact that a customer needs a /24 doesn't automatically imply that he needs control over the reverse DNS. Our support staff usually adds/changes records to zones within 30-60 minutes. We monitor every reverse zone we delegate, if the customer thinks he must have control. However there is no obligation to do so and if the customer breaks the zone and is unable to put things straight and keep it that way, we remove the delegation.
Well for this to be effective you have to own the DNS server. Then again for really small shops this box will already be the mail server and will already have a MTAMARK or are you going to ban your customers from running mail servers on their bussiness class accounts.
A lot of the problems arise from 0wned broadband hosts. With SPF or Sender-Id and even DomainKeys spammers can use throwaway domains like qrve079uyvqweriuq.biz, put the IP addresses of the 0wned broadband hosts in the records of the domain and voila, the 0wned host is a legit mailserver for qrve079uyvqweriuq.biz. With short TTLs for that records they can exchange the "mailservers" fast. They control the reputation system (i.e. the forward zone).
Nothing will magically stop spam. One can reduce / channel / identify it by applying a number measures. None of those measures is 100% effective.
A lot of the methods could be some orders of magnitude more effective if some admins would take more care. Some of methods don't require anything more than a bit of thinking. Not breaking RtoL hierarchy of DNS is one of them. A naming scheme hNNN.mail.example.com instead of mailNNN.example.com is another (so a easy whitelist *.mail.example.com could be used). Using 4.3.2.1.dyn.rev.example.com instead of dyn-1-2-3-4.rev.example.com (as has been pointed out in this thread before) would help a lot. Everyone agrees, no one acts, nothing changes. RP (Responsible Person) records are there since RFC 1183. Populate the DNS and make the work of abuse reporting tools more easy to contact the right person, instead of having to wade through whois servers with broken referrals. It even helps ones own abuse desk, as one gets one email and not 5 or 6 to all kind of addresses the reporting tools think *could* be right as they found them somewhere, related or not. MTAMARK gives caring admins one of a few instruments to make their IP different and to give it a better reputation. If an address provider refuses to make this possible, one can always complain and raise the pressure - or get an address provider who cares. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin"