Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote: Lots. I'm sure that there are lots of ISPs/IAPs on NANOG that do RFC 2317 style delegations for their customers. How many is lots? And how often do the IP addresses of (outgoing) Mailservers change within a subnet? None of ours has changed in the last 10 years and our customers (mainly business customers) usually never change them, either. Every one of them would need to upgrade their servers to support DNAME. Their clients would also need to upgrade their servers to support DNAME as they should be stealth servers of the parent zone, to allow local lookups to work when the external link is down. If MTAMARK requires DNAME then RFC 2317 style delegations would require them, too. None of which is true. 1 CNAME 1.0/25.2.0.192.in-addr.arpa. works exactly the same way _send._smtp._srv.1 CNAME _send._smtp._srv.1.0/25.2.0.192.in-addr.arpa. does. No special magic required. One can even use BINDs $GENERATE statement for that. Unless I am missing something I don't know of any RFC that prohibits that. \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
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote: Lots. I'm sure that there are lots of ISPs/IAPs on NANOG that do RFC 2317 style delegations for their customers. How many is lots? Does it really matter? Even if it was only one site the problem would still have to be addressed. I know that it is lots more than one because I've had to help lots of sites debug their RFC 3217 style delegation. And how often do the IP addresses of (outgoing) Mailservers change within a subnet? None of ours has changed in the last 10 years and our customers (mainly business customers) usually never change them, either. Stablility has nothing to do with whether a site can just go and add the records or not without having to talk to their address provider. Every one of them would need to upgrade their servers to support DNAME. Their clients would also need to upgrade their servers to support DNAME as they should be stealth servers of the parent zone, to allow local lookups to work when the external link is down. If MTAMARK requires DNAME then RFC 2317 style delegations would require them, too. None of which is true. 1 CNAME 1.0/25.2.0.192.in-addr.arpa. works exactly the same way _send._smtp._srv.1 CNAME _send._smtp._srv.1.0/25.2.0.192.in-addr.arpa. does. No special magic required. One can even use BINDs $GENERATE statement for that. Unless I am missing something I don't know of any RFC that prohibits that. RFC 2317 CNAMES the well known name. MTAMARK wants to add a prefix to the well known name. What happens when someone else decides to add yet another scheme and another and another. The point of RFC 2317 style delegations was to give control. You don't get control without switching to using DNAMES. You are still at the mercy of your address supplier when you want to make changes in your reverse in-addr.arpa space otherwise. Mark \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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Wed, Jan 26, 2005 at 07:31:44AM +1100, Mark Andrews wrote: Does it really matter? Yes it does. (As we all know at least since the Godzilla movie size does matter ;-) It has direct influence on the deployment. Even if it was only one site the problem would still have to be addressed. I know that it is lots more than one because I've had to help lots of sites debug their RFC 3217 style delegation. I have adressed and solved the problem in my last posting. Stablility has nothing to do with whether a site can just go and add the records or not without having to talk to their address provider. Sure it has. If it never happens you try to solve a problem that does not exist. But, see below why this problem is even a good thing. RFC 2317 CNAMES the well known name. MTAMARK wants to add a prefix to the well known name. What happens when someone else decides to add yet another scheme and another and another. A man is in the desert for a week without water, dying with thirst. A van passes by with 10 bottles of water. The man is begging the driver to give him a bottle and the driver replies: I can't give one to you because if there are 9 others I would have none left. There is no one else and there is no other scheme. We'll solve that issue when there is and maybe then DNAME is widely deployed and it isn't an issue at all. What happens if someone wants to add a new record type and another and yet another? This is even more complicated to deploy and it happens all the time. The point of RFC 2317 style delegations was to give control. You don't get control without switching to using DNAMES. So you say RFC 2317 failed miserably in its goal? You are still at the mercy of your address supplier when you want to make changes in your reverse in-addr.arpa space otherwise. You are at the mercy of your address supplier - to do RFC 2317 delegation at all (a lot don't) - to get the delegation right - to not fsck the delegation some point later - to not fsck the zone, so it will expire - to not fsck the dns server config - to not fsck the routing - to not fsck the routing filters - to not block port 25 or any other - ... But - this is the main advantage of MTAMARK: spammers cannot easily mark an IP address as a valid mailservers without support by the address provider. Cracking hosts or abusing them through viruses/worms doesn't help, as they can't set the labels giving them good reputation. With other methods they can easily turn an 0wned host into a valid mailserver for a (vanity) domain, with MTAMARK they can't set the I'm a mailserver flag by themselves. \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
Re: fixing insecure email infrastructure (was: Re: [eweek article]
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
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Fri, Jan 14, 2005 at 10:05:05AM +1100, Mark Andrews wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. How many legit mailservers get their revDNS from RFC 2317 style delegations? Marking hosts MTA=no is an addon for an explicit block. I'd assume most ISPs cannot simply mark their revDNS with MTA=no without changing contracts, but even adding MTA=yes would be of a lot of help. And it is really easy and doesn't have any negative side effects ;-) \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
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Fri, Jan 14, 2005 at 10:05:05AM +1100, Mark Andrews wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. How many legit mailservers get their revDNS from RFC 2317 style delegations? Lots. I'm sure that there are lots of ISPs/IAPs on NANOG that do RFC 2317 style delegations for their customers. Every one of them would need to upgrade their servers to support DNAME. Their clients would also need to upgrade their servers to support DNAME as they should be stealth servers of the parent zone, to allow local lookups to work when the external link is down. If you hace a RFC 2317 style delegation then you are almost certainly doing your own mail support in addition to your own DNS support. Marking hosts MTA=no is an addon for an explicit block. I'd assume most ISPs cannot simply mark their revDNS with MTA=no without changing contracts, but even adding MTA=yes would be of a lot of help. And it is really easy and doesn't have any negative side effects ;-) \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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
Because there is no data protection on many databases (such as .com registrars who are forced to sell the data if requested), people lie when registering, because it is the only tool they have to protect their privacy. Yup. Our ICANN contracts both require us to sell bulk registrant data, and require us to maintain :42 and :80 (FORM+POST) whois servers, both unconditionally, to satisfy the trademarks interest group. The perfect open whois to fight spam claim exchanges 40,000,000 valid (or not dysfunctional in this particular context) for two or more orders of magintude smaller invalid and dysfunctional (in this partuclar context) addresses. Because registrar-registrar predation via whois data mining is a reality, registrars rate limit or otherwise attempt an ACL on both :43 and :80 whois service, and data format variation is a form of defense. It prevents the marginals who can't write a simple parser from theft via slamming the registrants. And since no one who wants whois data who isn't stealing registrants is paying us, grand unifying schemes aren't a registrar insterest. Again, look to the marks people, now accompanied by the new total information law enforcement people for the primary actors. As I've previously pointed out, neither of those two interest groups is fundamentally interested in SMTP. Fix the data protection problem and you'll have a better case to force people to register proper information. Bingo!
Re: fixing insecure email infrastructure (was: Re: [eweek article]
That's bad sincd DNAME is deprecated and has been removed from BIND. Owen Really? Thats news to me. RFC 2672, Non-Terminal DNS Name Redirection, is still a proposed standard http://www.ietf.org/iesg/1rfc_index.txt. If you are thinking about RFC 3363, Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). It does NOT deprecate DNAME. There is no UPDATES RFC 2672 at the top. I was well aware that it didn't deprecate DNAME when it passed through the WG. I would have complained long and loudly if it did. Mind you, in hind site, I should have a strongly argued that section 4 of RFC 3363 just be deleted. All it has done is generate confusion about the status of DNAME and to top that the opening sentence contains assertions which don't hold water once you think about them a little bit. DNAME is just as useful with nibbles in the reverse tree as it was with bitlabels. Take RFC 2874, DNS Extensions to Support IPv6 Address Aggregation and Renumbering, and redo the examples with nibbles. Everything just works. To renumber the reverse you need to get the appropriate DNAME records updated. You don't need to re-establish several levels of delegation under IP6.INT. Yes I expect the RIRs to add DNAMES not NS records at some point in the future for IP6.INT. For the forward part all the end systems just register their new addresses in the DNS using UPDATE. Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
The current pretense of privacy is nothing more than a convenient mechanism for registrars to pad their wallets and evade responsible for facilitating abuse. As an aside, I used a (wicked big) competitor's privacy service to regsiter a domain for a political worker who wanted to whistleblow but not be identified. My customer could now use a web log service such as Duncan Black did under the name of atrios, and obtain casual (but not subpoena-proof) data protection (non-publication of customer profile data). Broadly I agree that privacy as a product under contract law is not a better solution than data protection as a right under human rights. However, data protection isn't as available to all potential registrants.
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Fri, 14 Jan 2005, Suresh Ramasubramanian wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. Cue DJB's kill A6 page http://cr.yp.to/djbdns/killa6.html Well, A6 is not DNAME; the only relation is that A6 needed DNAME in the reverse lookup direction. DNAME is quite useful in the forward lookup direction, particularly since synthesizing CNAMEs for older resolvers is part of the requirement. It allows moving of an entire subdomain wholesale from one parent to another without creating a flurry of CNAMEs. This helps even more if you have a wildcard subdomain in there. 8-) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: fixing insecure email infrastructure (was: Re: [eweek article]
That's bad sincd DNAME is deprecated and has been removed from BIND. Really? Thats news to me. RFC 2672, Non-Terminal DNS Name Redirection, is still a proposed standard http://www.ietf.org/iesg/1rfc_index.txt. yes, and ISC-TN-2002-1 (see www.isc.org/pubs/tn/) is still timely. -- Paul Vixie
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Steven Champeon wrote: on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote: On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... I think Steve was referring to some things that can be implemented right away, like if you operate a mailserver, please make sure that it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com, try to give it unique and non generic rDNS, preferably with a hostname that starts off with smtp-out, mail, mta etc) Yep. And it helps if the rDNS is right-anchored, (uses subdomains to distinguish between various assignment types and technologies) a la 1-2-3-4.dialup.dyn.example.net 4-3-2-1.dsl.static.example.net ^^^ as opposed to dyn-dialup-1-2-3-4.example.net static-dsl-4-3-2-1.example.net as the former is easier to block using even the simplest of antispam heuristics. I'd love to see a convention, or even a standard, arise for rDNS naming of legit mail servers. But I'll happily settle for decent and consistent rDNS naming of everything else ;) What is wrong with MTAMARK? MTAMARK tags the reverse entries of IP addresses where SMTP servers are. Fixes this problem very fast, efficient and with little effort (script magic to regenerate the reverse DNS entries). ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt -- Andre
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 0) for the love of God, Montresor, just block port 25 outbound already. If there is no escape / exemption (as proposed by William Leibzon), then, as a consumer, I scream OVER MY DEAD BODY!!!. I want to be able to manage an email server when I subscribe to an ISP. In any case, it would no longer be Internet access. See the Internet-Draft draft-klensin-ip-service-terms-04.txt, Terminology for Describing Internet Connectivity.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Since this list is NANOG, it is reasonable that it has a North American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) Requesting rDNS means I don't want to receive email from Africa.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. Because there is no data protection on many databases (such as .com registrars who are forced to sell the data if requested), people lie when registering, because it is the only tool they have to protect their privacy. Fix the data protection problem and you'll have a better case to force people to register proper information. 5) whois data MUST be normalized and available in machine-readable form (such as a standard XML schema) RFC 3981
RE: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Basically a call to operators to adopt a consistent forward and reverse DNS naming pattern for their mailservers, static IP netblocks, dynamic IP netblocks etc. ...and to ISPs to facilitate the process by supporting their users who want to run mail servers, and helping the rest of us use such techniques to quarantine the spew from zombies and less conscientious mail admins. I'm always willing to be educated on why it is impossible for any given ISP to maintain an in-addr.arpa zone with PTRs for their customers who wish to be treated like real admins, as opposed to casual consumer-grade users with dynamically assigned addresses. The problem is it is easier to set it up with a single standard 4-3-2-1.dialup.xyzisp.com then to change the IN-ADDR to mail.customer2.com. I only have an rDNS entry on the box at home because I used to work for the ISP. It's still there only because they probably haven't noticed, and will not until I draw attention to it or I give up the space if I cancel service. Still, it took me 3 minutes to put rDNS on most of 7 of 16 in my /28. It existed in their provisioning system to do it, but no one knew how. We couldn't even market it as a service, because it didn't exist in the system. I can't imagine, though, SBC being able to cope with tens of thousands of small business DSL accounts suddenly needing rDNS on their static IP's. Another question, though, is how they handle IN-ADDR and swip for dedicated circuits. If they can do it for a T1 customer, can they do it for a DSL customer? Maybe an online form the customer can maintain? Lord knows that would be better then trying to call their DSL tech support . . . Joe Johnson
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Thu, Jan 13, 2005 at 12:26:47PM +0100, Stephane Bortzmeyer wrote: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. Because there is no data protection on many databases (such as .com registrars who are forced to sell the data if requested), people lie when registering, because it is the only tool they have to protect their privacy. Those people are fooling themselves. Much of the domain registration data is already being offered for sale (by spammers, of course) and no doubt, when it suits their purposes to do so, the same people will find a way to acquire the supposedly private data behind the rest. (How are they getting the data? I don't know. Could be weak registrar security, could be a backroom deal, could be a rogue employee. But there is demand for the data, and plenty of money to pay for it, therefore it *will* be acquired and sold.) The current pretense of privacy is nothing more than a convenient mechanism for registrars to pad their wallets and evade responsible for facilitating abuse. ---Rsk
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Thu, 13 Jan 2005 12:21:04 +0100, Stephane Bortzmeyer said: American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) That is indeed a problem that needs to be solved if you want any sort of rDNS-based service to work well. Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. I'm not on our campus. But I can see it from out my office window. (The official campus starts across the street from me). I'm about 4 hours drive southwest of Washington DC. professory.cesa.vt.edu is 195.176.186.74, and has a proper PTR entry back. It's a host of ours. It's in Switzerland at our Center for European Studies and Architecture. So what did that rDNS entry tell you about its location that you didn't know from 195.176/16? pgp4lmIbolmK5.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an
On Thu, Jan 13, 2005 at 10:21:20AM -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 45 lines which said: Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
on Thu, Jan 13, 2005 at 12:21:04PM +0100, Stephane Bortzmeyer wrote: On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Since this list is NANOG, it is reasonable that it has a North American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) Seems this needs to be fixed, then. Not my problem. Requesting rDNS means I don't want to receive email from Africa. See above. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 04:51:34PM -0800, william(at)elan.net wrote: ...a very long and useful and informative message, for which I thank him. Off to go decipher the madness that is RFC3982, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an
Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind. Howdy Stephane, It is also an area where many cctld operators maintain their registration data using spreadsheets, and whois isn't :43. Not an issue of activel malfeasence, other than early adopter attitudes towards late, and challenged adopters. As you note, there are many reasons behind [it, the impossibility to get a PTR record or a :43 server connect]. Eric
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. What he was pointing out her is that a majority of African ISPs do not even have the ability to assign rDNS to their address space. This is an unfortunate fact which should get somewhat better as a result of ARIN policies 2002-3 and 2003-15. I don't know to what extent those policies have helped yet, but, at least it is much easier for African ISPs to get direct allocations now. In essence, it is virtually impossible for a small-medium business in Africa to set up a mail server and have rDNS entries created for it because their ISP doesn't control the IN-ADDRs and the imcumbent Telco doesn't want to do anything they don't absolutely have to for the competitive ISPs. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpObGpMqS1A4.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Thu, 13 Jan 2005 11:35:23 PST, Owen DeLong said: Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. What he was pointing out her is that a majority of African ISPs do not even have the ability to assign rDNS to their address space. Ahh.. I've had so many people of late say words to the effect of I want rDNS so I can implement blocking geographical that I didn't realize what he meant was Implementing it means an Africa-shaped projectile wound in your foot.. ;) pgpsiKd1CySxQ.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article]
What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. There are other issues but hear is not the correct place to debate them.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an
On January 13, 2005 at 17:41 [EMAIL PROTECTED] (Stephane Bortzmeyer) wrote: Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind. That's because one of their leader's widows has 10 million PTRs they can't get to without your help and are more than willing to give you 15% of them if you would just deposit... I think the answer to not having rDNS in such an endemic way is to arrange to have your email delivered by a host which does like hotmail or whatever or pay someone to accept your non-rDNS connections as a special case and forward it along. Put another way, I don't know much chaos we should accomodate when solutions really aren't very difficult. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
Re: fixing insecure email infrastructure (was: Re: [eweek article]
That's bad sincd DNAME is deprecated and has been removed from BIND. Owen --On Friday, January 14, 2005 10:05 +1100 Mark Andrews [EMAIL PROTECTED] wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. There are other issues but hear is not the correct place to debate them. -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgpj3GEskDY9c.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Thu, 13 Jan 2005, Owen DeLong wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. Owen No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Thu, 13 Jan 2005 22:43:24 -0800 (PST), william(at)elan.net [EMAIL PROTECTED] wrote: On Thu, 13 Jan 2005, Owen DeLong wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. Cue DJB's kill A6 page http://cr.yp.to/djbdns/killa6.html -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Once upon a time, Steven Champeon [EMAIL PROTECTED] said: 7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses) One problem I have with this one is people do forge reports, and there is no way around that. Also, as long as there are networks that don't enforce source address filtering, port probing complaints cannot be validated (I take them as valid unless proven otherwise, but we have had a few that appear after the fact to be forged and/or spoofed). If you _always_ take someone off-line on a single complaint, you make it easy for someone to get someone else kicked off. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 10:32:13AM -0600, Chris Adams wrote: Once upon a time, Steven Champeon [EMAIL PROTECTED] said: 7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses) One problem I have with this one is people do forge reports, and there is no way around that. Also, as long as there are networks that don't enforce source address filtering, port probing complaints cannot be validated (I take them as valid unless proven otherwise, but we have had a few that appear after the fact to be forged and/or spoofed). If you _always_ take someone off-line on a single complaint, you make it easy for someone to get someone else kicked off. Think of it as two separate requirements, one dependent on the other. 1) I'm tired of hearing stories about ISPs who let Spammer X continue because there weren't enough complaints, and 2) once you've verified that a reported infected host IS infected, take 'im offline ASAP. Or, restate it as no more abuse desk role account autoack ignorebots. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed ... All? Even those unpublished and therefore non-resolving? Sensible for the scoped-to-totality trademarks weenies who argue that the stringspace is a venue for dilution, whether the registry publishes all of its allocations or not. I'm not sure why anyone cares about a very large class of domains in the context of SMTP however. 5) whois data MUST be normalized and available in machine-readable form There are some registries that use paper to answer registration queries. I'm not sure why anyone cares about a very small class of domains in the context of SMTP however. Aggregation and reformatting have their place. We explored this in the whoisfix bofs but no working group congealed around fixing :43. Again, I'm not sure why anyone cares about a very large class of whois:43 output sources in the context of SMTP however. Eric
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 12:55:06PM +, Eric Brunner-Williams in Portland Maine wrote: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed ... All? Even those unpublished and therefore non-resolving? Sensible for the scoped-to-totality trademarks weenies who argue that the stringspace is a venue for dilution, whether the registry publishes all of its allocations or not. Why would it matter if you deactivated an unpublished/non-resolving domain? If you care about the domain, keep the whois data up to date and accurate. I'm not sure why anyone cares about a very large class of domains in the context of SMTP however. For one thing, a very large class of domains are being used as throwaways by spammers, who use them up at a rate approaching 1 every six hours for some of them, after which they are abandoned. In the meantime, their whois info is inaccurate or (thanks, VRSN!) not yet published, anyway, so the criminals can hide behind the fact that nobody seems to care about whether whois is accurate. This destroys any potential protection value whois might offer, and allows spammers and other abusers to fly below the radar, accountable to nobody. 5) whois data MUST be normalized and available in machine-readable form There are some registries that use paper to answer registration queries. And? I'm not sure why anyone cares about a very small class of domains in the context of SMTP however. It's not a very small class of domains with more or less unpredictable data formats. It's ALL of them, or damn near. I should be able to write a program, relatively easily, that would give me any available contact or registrant information on a per-field basis, from any whois service. The wide variety and nonuniformity of the existing services makes that task daunting at best; that the information is likely wrong or stale is enough to undermine whatever faith we might have had in it once. Aggregation and reformatting have their place. We explored this in the whoisfix bofs but no working group congealed around fixing :43. What were the objections/sticking points? Again, I'm not sure why anyone cares about a very large class of whois:43 output sources in the context of SMTP however. It's not just the context of SMTP. It's the context of accountability on the Internet, which bad actors are exploiting, currently, via SMTP. I really do think it would benefit some folks here to read up on the broken windows theory of crime prevention. The majority of the 'Net is looking more and more like a warehouse full of broken windows (no, this isn't a deliberate pun on the OS) and it's no surprise that we waste many billions of dollars a year as a result. Let people get away with petty crimes, and they get the message loud and clear that you probably don't care about the big crimes, either - while giving them a great opportunity to perform those crimes in an atmosphere of an almost complete lack of accountability. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
0) for the love of God, Montresor, just block port 25 outbound already. What is wrong with dedicating port 25 to server to server communication with some means of authentication (DNS?) to ensure that it is indeed a vaild mail server. Mail clients should be using port 587 to submit messages to their local MTA. Adi
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 01:49:53PM +, Eric Brunner-Williams in Portland Maine wrote: Why would it matter if you deactivated an unpublished/non-resolving domain? How do you deactivate an unpublished/non-resolving domain? You may borrow a registrar or registry hat if that is useful to answer the question. I suppose it depends on how you define 'unpublished'; and how you define 'non-resolving'. A year and a half ago, I was subjected to a joe job by Brian Westby (the bounces stopped the day after the FCC fined him), using several domains, among them adultwebpasshosting.org. It had been registered, was in whois with obviously forged data, resolved to an IP, and I reported it to ICANN for having invalid whois data. It took them, as near as I can tell (I was never notified of the action taken) at least a year to have it removed from the root dbs. I'd like to avoid going through that nonsense again. If you care about the domain, keep the whois data up to date and accurate. That is the policy articulated by the trademarks stakeholders in the ICANN drama, but how does their policy, which is indifferent to any condition but strindspace allocation, relate to any infrastructure that has one or more additional constraints? Please see my other message. Allowing domains with invalid whois data to remain in use facilitates abuse in other realms. I'm not sure why anyone cares about a very large class of domains in the context of SMTP however. For one thing, a very large class of domains are being used as throwaways by spammers ... Do you know anything about the acquisition pattern at all, or if there is any useful characterization finer in scope than all? One of the domains we host has been the victim of an ongoing joe job. The sender forges an address in the domain for the SMTP MAIL FROM: and when the message(s) bounce(s), we get the DSN(s). I've got bounce messages here going back several months. In the past month (since Dec 1), I've seen (not counting the tens of thousands of DSNs I've refused from idiot outscatter hosts): count domainreceived registered diff - --- -- --- 13 kakegawasaki.com Jan 6 2005 Dec 23 2004 14d 7 oertlika.com Jan 7 2005 no whois info n/a 6 mikejensen.info Dec 30 2004 Dec 9 2004 21d 5 kristinaficci.infoJan 8 2005 Dec 22 2004 17d 4 rhianjonesmuchos.com Jan 10 2005 no whois info n/a 4 krauszolts.info Jan 7 2005 Dec 22 2004 16d 4 gregbryant.info Dec 31 2004 Dec 9 2004 22d 4 elitke.info Dec 1 2004 Nov 28 2004 3d 3 tlepolemosmilos.com Jan 9 2004 no whois info n/a 3 latvianet.infoDec 25 2004 Dec 3 2004 22d 3 judsononly.info Dec 30 2004 Dec 12 2004 18d 2 tarumisalata.info Dec 28 2004 Dec 12 2004 16d 2 sawawer.net Dec 13 2004 no whois info n/a 2 sakkama.info Dec 15 2004 Dec 3 2004 12d 2 purkyne.info Dec 9 2004 Nov 28 2004 11d 2 kazoplace.com Dec 31 2004 no whois info n/a 2 katrianne.infoDec 1 2004 Nov 28 2004 3d 2 heinrichkayser.info Dec 30 2004 Dec 9 2004 21d 2 cavaradossi.net Dec 23 2004 no whois info n/a 2 brangane.info Jan 3 2005 Dec 18 2004 16d 1 wurmhug.com Jan 1 2005 no whois info n/a 1 ulissedinires.com Dec 24 2004 Nov 11 2004 13d 1 onlycomello.info Dec 19 2004 Dec 3 2004 16d 1 mysalpetriere.com Dec 26 2004 Dec 23 2004 3d 1 konstitutsiya.com Dec 17 2004 Dec 3 2004 14d 1 eugenisisplace.info Dec 27 2004 Dec 12 2004 15d Very few of these sighted span more than an 18 hour period between first and last appearance in a bounce. All those I've tested simply redirect to some porn site or other; for a list from November, see below: domain redirects to
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 12:41:44PM -0600, Adi Linden wrote: 0) for the love of God, Montresor, just block port 25 outbound already. What is wrong with dedicating port 25 to server to server communication with some means of authentication (DNS?) to ensure that it is indeed a vaild mail server. Nothing at all. That's more or less what I proposed, though I'd prefer to see something TODAY, like the easily implemented rDNS fix, rather than wait any longer for SPF/DomainKeys/etc. to go through a zillion rounds of argument. As it stands, I reject a rather large percentage of the spam delivery attempts here using generic rDNS as a basis. (Either in the rDNS of the connecting host itself or in the HELO; the latter is responsible for ~75%-80% of the rejections, assumed to be almost entirely zombie-originated). Mail clients should be using port 587 to submit messages to their local MTA. Agreed. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Numerous (as in at least hundreds, probably more) of spam gangs are purchasing domains and burning through them in spam runs. In many cases, there's a pattern to them; in others, if there's a pattern, it's not clear to me what it might be. From my point of view, pattern is which registars are getting the buys, for which registries, where the ns's are hosted, and for domains used in the return value side, hosting details. The latter to reduce to RIR CIDRs. There is more, but that is the first cut, localization of registrar(s) and registries and CIDRs. This bunch prefers domains in .info -- no doubt motivated in part by things like the recent $1.95 sale on such domains. OK. Now you've identified price as a significant control variable. There are registrars that don't sell .info. I don't. There are registars that don't sell to directly to registrants. I can think of half a dozen of us who only sell to corporations and bonafide people who buy reasonable names. Transcendental numbers in decimal character form are reasonable. Your two example sets are not reasonable. The dirty little secret is that all this activity on the part of spammers is a gold mine for registrars. This isn't going to make me think you can add or subtract. It's gotten so bad that -- to a darn good first approximation -- if you find a domain in the .biz or .info TLDs I agree, and don't sell .biz, .info or .name, or .cc or .tv or .bz or any of the obvious repurposed cctlds, with the exception of my friend Bill Semich's .nu, which actually means something in Sweden for local reasons. I do plan to sell .aero, .coop and .museum, however. In case it is inobvious, there is a possibility that part of _your_ problem (and a big part of my problems) can be placed at the figurative door of a 501(c)(3) located in California. The answer? (1) no obfuscated registrations (2) mass, fast, permanent confiscation of spammer domains (3) requirement for reasonably correct domain registration info ... and (4) publication of all WHOIS data in a simple, easily parseable form ... Nothing in this laundry list that makes the cost of bad business for my competitors rise, see add and subtract, above. Try the following: 1,$s/registrars/isp/g and 1,$s/registry/rir/g, and 1,$s/domain/ipv4_addr/. If you're still keen on your approach, then it might be a good one. I've replied after removing your personal identifiers back to NANOG. I appreciate the data, but I want the discourse to be multicast. Eric
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
I suppose it depends on how you define 'unpublished'; and how you define 'non-resolving'. Your opening remark was that policy foo must be applied to all domains. This doesn't accomplish anything for the set of domains that will never be published (registry reserved strings), nor those that absent seperate acts of malfesance, will always have a very low average association with disfunction -- the 50% of the .net namespace that actually goes to real boxen owned and operated by real people. Between, and in addition to these two samples, there are classes of domains that are vastly less likely to be used in uce and equivalent schemes. The class of domains purchased simply to take them out, such as Hamming distance buys around a defended mark, may never resolve. All is too blunt a tool. I reported it to ICANN for having invalid whois data. It took them ... ... a year to have it removed from the root dbs. That is an ICANN issue. It may come as a surprise to you but for the past few years the ISP Constituency has ceased to exist, and has been folded into Marilyn Cade and Philipe Sheppard's Business Constituency. Please see my other message. Allowing domains with invalid whois data to remain in use facilitates abuse in other realms. If it isn't fixing insecure email infrastructure, then it needs to find a thread and/or list of its own. The little table of domain names and redirects is slightly useful, but it would be more useful if your data could show registrar clustering. I'd be delighted if you have pointers to a paid whois reformatter, but I still believe strongly that it should not be necessary. The quality of data usually has a relationship with the cost of care that has gone into that data, just like abuse desks. Eric
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 05:28:45PM +, Eric Brunner-Williams in Portland Maine wrote: All is too blunt a tool. So, then, when registering a domain, there should be a little checkbox saying I intend to abuse the Internet with this domain? It makes no sense to have a universal policy if it is not universally enforced. Why is it considered such a crazy proposition that domains should have valid and correct whois data associated with them? Please see my other message. Allowing domains with invalid whois data to remain in use facilitates abuse in other realms. If it isn't fixing insecure email infrastructure, then it needs to find a thread and/or list of its own. Bah. You're saying that you're uninterested in discussing the root causes that allow and even encourage abuse to occur in specific realms. I guess you're not interested in actually fixing insecure email infrastructure. The little table of domain names and redirects is slightly useful, but it would be more useful if your data could show registrar clustering. Why should this matter? Spammy can always choose a different registrar every day. So what? He is registering domains for use in abusive and criminal acts, and the message I'm getting from you is that it should only be of concern to you if he uses the same registrar? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Why is it considered such a crazy proposition that domains should have valid and correct whois data associated with them? There is no relationship between data and funcion. The data is not necessary to implement function-based policy. Bah. You're saying that you're uninterested in discussing the root causes that allow and even encourage abuse to occur in specific realms. I guess you're not interested in actually fixing insecure email infrastructure. I have no idea what specific realms you could be referring to. The little table of domain names and redirects is slightly useful, but it would be more useful if your data could show registrar clustering. Why should this matter? Spammy can always choose a different registrar every day. So what? He is registering domains for use in abusive and criminal acts, and the message I'm getting from you is that it should only be of concern to you if he uses the same registrar? OK. The choice of registrar, registrar policy, registrar price, and so on isn't data that could be of use to anyone ever. But you're going to get valid and correct whois data from all registrars. How will you get that? What does valid and correct mean? Does it apply to all the records in a single domain registration, or just some of them? Eric
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 04:24:42PM +, Eric Brunner-Williams in Portland Maine wrote: (quoting Anonymous): Numerous (as in at least hundreds, probably more) of spam gangs are purchasing domains and burning through them in spam runs. In many cases, there's a pattern to them; in others, if there's a pattern, it's not clear to me what it might be. From my point of view, pattern is which registars are getting the buys, for which registries, where the ns's are hosted, and for domains used in the return value side, hosting details. The latter to reduce to RIR CIDRs. I provided the IPs to which all of the latter domains resolved at the time I checked. All went to four IPs, all in China, three in the same network. The nameservers exhibit similar behavior, though often also with Brazilian nameservers along with Chinese. Not in the last month, tho: nameservers: 16 ns1.anwoo.com 202.67.231.145 HKNET-HK 14 ns1.eslom.com 61.128.196.155 CHINANET-CQ 12 ns1.epoboy.com 222.51.91.226CRTC 12 ns1.bomofo.com 221.5.250.122CNCGROUP-CQ 4 ns1.lenpo.com 207.234.224.202 AFFINITY-207-234-128-0 4 ns1.boozt.com 218.7.120.81 JINDU-COMPUTER-NET-COM 2 ns1.mynameserver.ca 202.67.231.145 HKNET-HK registrars by whois server: 15 whois.afilias.info 3 whois.planetdomain.com 2 whois.godaddy.com 2 whois.domainzoo.com 1 whois.registrationtek.com 1 whois.joker.com So? Of course .info is handled by afilias. Sponsoring registrars for .info domains mentioned upthread: 9 R126-LRMS - Enom 4 R239-LRMS - Primus 2 R171-LRMS - GoDaddy There's your clustering. Feel free to somehow reduce these to CIDRs or ASNs; they're not used in the message headers anyway, so all you can do is block the redirection for your users, but not prevent them from being deluged with the spam itself, nor prevent me and others from being deluged with the bogus DSNs. So what? Eventually, better antispam techniques will lead to the ability to block messages from or referencing domains with banned nameservers. And then spammy will set things up so that he has a new nameserver for every run. And we'll still have insecure email, because he'll have continued to get away with it, because he can hide behind private whois for his domains registrations, he'll continue to burn through the net namespace leaving nothing but scorched earth, and none of the underlying conditions will have been addressed. It's no longer a simple matter of blocking the sender origin, botnets have taken care of that. It's no longer a matter of blocking known spammy domains in SMTP envelopes; they're forging them. It's not a matter of blocking mail with known spammy domains in it, as these are one-a-day throwaway redirectors. It's not a matter of blocking mail with domains that point to rogue nameservers, ASNs, or CIDRs, spammy can register new domains and use new ones every day. It's not a matter of any of these things, though I use them all, and with some effect. The problem is that spammy is getting away with this by modifying his tactics slightly and keeping a step ahead of the game, and because few understand or care about actually /fixing the underlying brokenness/ that lets him get away with it day after day. There is more, but that is the first cut, localization of registrar(s) and registries and CIDRs. I fail to see how isolating registrations to a single registrar changes the facts on the ground - if anything, you're already showing that you are at least one step behind Spammy, by making this a requirement. Or, alternately, you're simply saying that those who care about net abuse are shackled by ICANN's bylaws and therefore we can do nothing. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Taking your comment in reverse order. Or, alternately, you're simply saying that those who care about net abuse are shackled by ICANN's bylaws and therefore we can do nothing. I don't think you have a monopoly on care (or clue) about net abuse, but it is pretty clear that you're not tall enough to ride the ICANN roller coaster. Thus far, all you've done is recycle the policy claim of the trademarks interests, a highly effective stakeholder and rational entity within ICANN, and the policy claim of the law enforcement interests, typically American, and not an organic ICANN stakeholder, and neither effective nor rational within ICANN (personal opinion, from the first FBI/LE UWHOIS meeting, March 2000 WDC if memory serves, to the present). Now why should that catch your attention? How about because neither of these policy authors (good, bad or simply ugly) care particularly about SMTP, in fact, the trademark policy author doesn't know that SMTP exists, because the use of trademarks in SMTP envelopes or bodies has not been argued (yet) to support a dilution claim. As the FBI/LE goal set isn't coherent or rational I'm going to assign it a protocol independent end point identifier goal, because I don't think the FBI/LE goal set is as limited as SMTP. This thread however is about SMTP, and some glop that might make it differently, or less insecure. So, if your primary policy tool is the same policy tool used by actors seeking ends indifferent to yours, either you are lucky or you are wrong. Now, is ICANN part of the problem space? It is for me, but I'm trying to compete with entrenched monopoly in the registry space that has the single greatest control over domain name policy, and entrenched cartel in the registrar space, and no technical issue, not secure operation of the root zone servers, correctness of the gtld zone servers, SLA metrics for gtld registry systems, data escrow, etc., has displaced the trademark position on whois:43 for the most important policy or operational issue for that corporation. My competitors (measured by market share) are for the most part indifferent to spam, porn, and social policy generally. Is it for you? Apparently not. So just leaving the trademarks people in charge should solve your problem in finite time. That means you may have already won. Eric
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
On Wed, 12 Jan 2005, Steven Champeon wrote: In a sense, I am suggesting a similar reallocation of resources. Rather than put those resources into filtering spam, I'd suggest that we will get a better result by shifting the resources into mail relaying and managing mail peering agreements. The spam will continue but users will move to using the secure mail architecture and won't see most of it. When the spammers also shift, there will be more tools to track them down or shut them down or simply to rate limit them. OK, sounds great. Let's start by making a few SHOULDs and MAYs into MUSTs. Its nearly impossible to make MAY into MUST. You can do slow update from MAY to SHOULD and from SHOULD to MUST over period of several years but in that case you also need to provide exact date when old SHOULD would be depreciated and until then you can't assume its a MUST. Some of the following could be accomplished in a few hours, Ha. You're kidding, right? some are probably not fixable unless we can reallocate some of the trillions of hours we waste fighting spam to the problem AND get some political support for accomplishing them (such as fixing whois once and for all). Its being worked on and CRISP just released new whois standard (see below) The migration is however a very slow process. Bear in mind that fixing email largely means fixing all the other brokenness that allows people to take advantage of email's trust model. I'd actually advocate for slow change in email infrastructure model. But I'll not elaborate at this time, see you in 2 months about it. So, then, it means fixing DNS conventions, abuse reporting support infrastructure (starting with whois), and broken mail server/client configurations. 0) for the love of God, Montresor, just block port 25 outbound already. There are legitimate uses of port 25, the question is that you need to have it blocked for anauthenticated use. There are the following ways to accomodate situations when some users need to have unblocked por25 when majority do not: 1. Blocking port25 by default and allowing authenticated users who have requested it to have it unblocked. That should be done by means of radius profile and I believe can be done with existing tools (I have not been involved in dialup for 4 years now but from what I remember I could easily have specific user profiles with different redirection data for port25). 2. Not blocking port25 by default but measuring all traffic that passes through (by that I mean just number of SMTP packets from each ip, not actually looking inside the packets). If any ip shows highier then normal usage then its temporarily blocked and ISP immediatly tries to contact the user to verify what they are not spamming. A complimentary to this is verification that source IPs are the ones assigned by ISP and not spoofed or IPs routed through vpn from some other place (see recent threads about, last one by Ejay when his dialup was abused). Both of the above are ways are practical and can be implemented by ISPs given enough interest. 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Corollary: any NONlegitimate mail source SHOULD be labeled as such (e.g., 1.2.3.4.dynamic.example.net or 4.3.2.1.dhcp.resnet.foo.edu) For UnifiedSPF I proposed before that special SPF record be published for the DNS hostname indicated by reverse dnsand that be checked to verify if it should or should not be source of email for that ip. 2) any legitimate mail source MUST HELO/EHLO with its own valid Internet hostname, not foo.local or SHIZNITSONY26354 or exchng1. Or, with their own bracketed IP. (Most do, many do not. There are very few valid reasons why not. Broken software should be fixed.) RFC2821 says that HELO should be valid hostname, so a few things that do happen right now are already against it. A new SPF draft also includes checking HELO which will essentially accomplish this in practice. CSV group is also advocating the same with different record syntax. Again it would be slow process of migration from when we start using and have to discard badly configured named to when majority (and 99% of those sending email) have these records and we can begin to advocate for MUST. 3) any legitimate mail source MUST be in a domain with functioning abuse and postmaster mailboxes, which MUST also be listed in the whois db entry for both that domain and IP space corresponding to the mail source. (Not difficult to do at all.) I beleive this is already in RFCs. Checking for this in real-time is somewhat impractical due to current whois system but we do have rfc-ignorant blacklist specifically for the reported bad whois domains. 4) all domains with invalid whois data MUST be deactivated (not confiscated, just
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
On Wed, 12 Jan 2005 17:40:10 -0500, [EMAIL PROTECTED] wrote: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. And how, exactly, does it indicate it's a mail server or source? In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: On Wed, 12 Jan 2005 17:40:10 -0500, [EMAIL PROTECTED] wrote: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. And how, exactly, does it indicate it's a mail server or source? In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... pgpug8CN5S1d9.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... I think Steve was referring to some things that can be implemented right away, like if you operate a mailserver, please make sure that it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com, try to give it unique and non generic rDNS, preferably with a hostname that starts off with smtp-out, mail, mta etc) Basically a call to operators to adopt a consistent forward and reverse DNS naming pattern for their mailservers, static IP netblocks, dynamic IP netblocks etc. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote: On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... I think Steve was referring to some things that can be implemented right away, like if you operate a mailserver, please make sure that it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com, try to give it unique and non generic rDNS, preferably with a hostname that starts off with smtp-out, mail, mta etc) Yep. And it helps if the rDNS is right-anchored, (uses subdomains to distinguish between various assignment types and technologies) a la 1-2-3-4.dialup.dyn.example.net 4-3-2-1.dsl.static.example.net ^^^ as opposed to dyn-dialup-1-2-3-4.example.net static-dsl-4-3-2-1.example.net as the former is easier to block using even the simplest of antispam heuristics. I'd love to see a convention, or even a standard, arise for rDNS naming of legit mail servers. But I'll happily settle for decent and consistent rDNS naming of everything else ;) Basically a call to operators to adopt a consistent forward and reverse DNS naming pattern for their mailservers, static IP netblocks, dynamic IP netblocks etc. ...and to ISPs to facilitate the process by supporting their users who want to run mail servers, and helping the rest of us use such techniques to quarantine the spew from zombies and less conscientious mail admins. I'm always willing to be educated on why it is impossible for any given ISP to maintain an in-addr.arpa zone with PTRs for their customers who wish to be treated like real admins, as opposed to casual consumer-grade users with dynamically assigned addresses. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!