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 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 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 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!
