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: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Wed, 12 Jan 2005 17:41:33 -0500, [EMAIL PROTECTED] wrote: The X.400 concepts of ADMD= and PRMD= really caught on, didn't they? ;) Peering in a world of 64K ASNs, mostly basically static, is a lot different than peering in a world of 40 million plus .COMs, many in motion. Most of the time, we're lucky if the MX record points to the right place Funny this should come up now... I've been working on a document to describe current Internet Mail architecture and it has taken an unexpected turn. In fact I am trying to add a section that deals with different Operators, as distinct from different functional modules. The reason is primarily because the inter-Operator boundaries define where trust relationships need to be decided and enforced. (The recent papers and discussions about tussle boundaries captures this issue really well.) As with so many problems with x.400, it is not that it was wrong to pay attention to one or another issue. The problem was that x.400 mixed everything together into a single, homogeneous and gargantuan pot, therefore requiring adopters to deal with an ungainly mass of specification and code, all at once. You really could not do adoption in incremental steps. Oh, and this all-or-nothing barrier hit the standards guys, too, since some required components did not show up for a long time. The x.400 admd/prmd was, in fact, an addressing construct, rather than merely being an operational and routing construct. Hence, an x.400 address was more like a source route. Arpanet/Internet experience has shown pretty serious scaling problems with visible source routing, uucp experience notwithstanding. The issue we are facing in the current discussion is operations, not addressing. So, for example, the fact of having a variety of operators does not show up in the address, any more than it does in an IP address. Rather, it shows up in routing and trust issues, just as it does with IP. Although lots of operational variety is possible and does occur, perhaps the most common operational scenarios are covered by: origin = [provider =] [provider =] destination And the equivalent to AS-AS trust assessment is not all of the domains in the world, but rather domains that involve MTA-MTA exchanges across operator boundaries. I believe the scale of this requirement is exactly the same as the AS-AS requirement. In fact, this is exactly the problem that CSV attends to. 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, 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: [eweek article] Window of anonymity when domain exists, whois not updated yet
= seriously, there have been various proposals ([ADV], etc) to facilitate legit UCE, but that hasn't slowed the arms race. How would you recommend that we make it easier for legit businesses? I don't propose that we make it easier for legit UCE. I'm simply pointing out that it's an arms race because we are solving the wrong problem. We are making it hard for people to send spam, therefore we are reaching the point where only criminals do so. I would rather see us focus on securing the email architecture. Secure submission is part of that, but for some reason people are unwilling to imagine an email system in which an ISP will only accept incoming messages from another ISP with which they have an existing agreement, i.e. rather like email peering. I happen to believe that a web of email peering agreements is the best way to get us to the point where it is difficult for anyone to anonymously send email because they *MUST* relay it through an ISP who will not accept the email for relay unless they have authenticated the user. This is solving a different problem. Spam is merely a symptom of an overly simplistic and insecure email architecture. Now that it has drawn our attention to the problem, I think we should ignore spam and focus on making a better email architecture that people can actually use again. --Michael Dillon
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Wed 12 Jan 2005, 12:23 CET]: [..] for some reason people are unwilling to imagine an email system in which an ISP will only accept incoming messages from another ISP with which they have an existing agreement, i.e. rather like email peering. You say this as if it's surprising that people are willing to accept communications from people they have not yet communicated with before. The world is not like your gated community. -- Niels. -- The idle mind is the devil's playground
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Wed, 12 Jan 2005 11:23:42 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I would rather see us focus on securing the email architecture. Secure submission is part of that, but for some reason people are unwilling to imagine an email system in which an ISP will only accept incoming messages from another ISP with which they have an existing agreement, i.e. rather like email peering. Ah right - let's go right back to the days of X-400 or possibly UUCP nodes Or if this is something newer, well, that's yet another proposal to take to the IETF This is solving a different problem. Spam is merely a symptom of an overly simplistic and insecure email architecture. Now that it has drawn our Changing the smtp protocol, or deploying an entirely new protocol that meets your rigid critieria are some things you have got to do then .. keeping in mind Vern Schryver's checklist of whether this is yet another final ultimate solution to the spam problem - http://www.rhyolite.com/anti-spam/you-might-be.html -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
Ah right - let's go right back to the days of X-400 or possibly UUCP nodes I don't want to rejuvenate an old obsolete protocol. Or if this is something newer, well, that's yet another proposal to take to the IETF I don't want to develop a new protocol. This is solving a different problem. Spam is merely a symptom of an overly simplistic and insecure email architecture. Now that it has drawn our Changing the smtp protocol, or deploying an entirely new protocol that meets your rigid critieria are some things you have got to do then .. keeping in mind Vern Schryver's checklist of whether this is yet another final ultimate solution to the spam problem - http://www.rhyolite.com/anti-spam/you-might-be.html I don't want to solve the spam problem so I don't consider that Vern's criteria applies to my suggestion. I suspect that my suggestion will make it easier to track down spammers, and provide additional tools to rate limit spam however I don't really care about whether or not my suggestion stops spam. I think that a secure email infrastructure is a good thing to have, in and of itself. By secure, I mean one in which messages get to their destination reliably, i.e. not lost in some spam filter, and one in which a recipient can reliably know where the message came from if they feel the need to track down the sender by other means. My suggestion is to use the existing email protocols but to make some operational changes in the way in which we use them. Mail peering is an operational change, not a protocol change. Forcing people to relay all email through their ISP's mail system is an operational change. Refusing to accept any incoming email that is not relayed by a mail peer is an operational change. Recently in London, the police decided to tackle the drug problem without making new laws. They implemented an operational change by ceasing to arrest people (in most cases) for smoking marijuana. They simply confiscate the drugs, warn them and walk away. As a result, they freed up a large number of police resources to focus on heroin and crack dealers. 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. --Michael Dillon
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
for some reason people are unwilling to imagine an email system in which an ISP will only accept incoming messages from another ISP with which they have an existing agreement, i.e. rather like email peering. You say this as if it's surprising that people are willing to accept communications from people they have not yet communicated with before. There is a difference between an ISP and a person who sends or receives email. I am only suggesting that ISPs should make mail peering agreements, not individuals. When I wrote a weekly column for [..] What if I'm not an ISP but want to limit the amount of third parties that are involved in delivery of e-mail between me and my friends? What if I'm one of http://www.vix.com/personalcolo/ ? To whom would I have to give what favours in order to be part of your mail cabal so I can communicate with people of different technical aptitudes? The world is not like your gated community. I have never lived in a gated community. Also, this new email architecture would not be a gated community. It may start off as a special service offered by a few larger ISPs to business clients, but over time I think most people will migrate to it. (You sound like Dr. Strangelove. That is a bad sign.) Right now I have freedom of communication. In your vision I would hand all that over to my ISP for the benefit of giving complete control over who can communicate with me to them. Why exactly do you think that would constitute a good deal for me? -- Niels. -- The idle mind is the devil's playground
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:52:43PM +, [EMAIL PROTECTED] wrote: I think that a secure email infrastructure is a good thing to have, in and of itself. By secure, I mean one in which messages get to their destination reliably, i.e. not lost in some spam filter, and one in which a recipient can reliably know where the message came from if they feel the need to track down the sender by other means. snip 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. Some of the following could be accomplished in a few hours, 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). Bear in mind that fixing email largely means fixing all the other brokenness that allows people to take advantage of email's trust model. 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. 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) 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.) 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.) 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. (NOTE: this will require fixing .org, among others whose public whois output is stale and not easily fixable via certain registrars). (Would probably take the most effort, but given a properly broad window of notification should be possible.) 5) whois data MUST be normalized and available in machine-readable form (such as a standard XML schema) - the I hate spam so I use a bogus contact addy excuse will be obsolete, as email infrastructure will be secured, right? (Honestly, how hard would this be? Gather up all the now-extremely varied formats, compromise on a superset, and map. Then put it all on a Web site or a reliable, distributed infrastructure. I'm REALLY TIRED of getting whois.$foo:111 connection refused when I'm trying to track down a spammer's support network). 6) all mail clients MUST support SMTP AUTH and the MSA port. (Many do.) All mail servers MUST support SMTP AUTH and the MSA port. (Some do.) 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) (Halve unemployment today. Retrain textile and manufacturing workers. Outsource the entire job. I don't care. Go read broken windows theory.) 8) all mail server, antivirus, and antispam software MUST NOT accept and then bounce (to the usually forged sender) bogus warnings or DSNs. (A chicken/egg problem, really, but some systems have NO excuse - such as A/V systems that helpfully inform me that some virus that ALWAYS forges the sender did so in a message sent from a system I have no control over.) 9) all mail servers and webmail systems, etc. MUST properly include tracking information in their Received: headers. (You might be surprised how many webmail systems and large ISPs fail this one. It's largely how 419/AFF scams are propogated.) 10) all HTML display engines MUST fix the bugs that allow for a link to say, 'phish.randomisp.net.br' appear as 'wamu.com' (Social engineering, but important in this day of hostile JPG images.) That should do it. I'd also ask that HTML email simply vanish, since I'm clearly already rubbing this lamp down to its bitter metal core... ;) -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us!
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
Right now I have freedom of communication. In your vision I would hand all that over to my ISP for the benefit of giving complete control over who can communicate with me to them. Perhaps you could explain to me just how you currently manage to get port 25 packets delivered to your friends without transitting your ISP? Or did you just mean freedom of communication in a rhetorical sense? And if you will trust an ISP to deliver port 25 packets then why wouldn't you trust them to deliver email messages? --Michael Dillon
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: [eweek article] Window of anonymity when domain exists, whois not updated yet
Right now I have freedom of communication. In your vision I would hand all that over to my ISP for the benefit of giving complete control over who can communicate with me to them. Perhaps you could explain to me just how you currently manage to get port 25 packets delivered to your friends without transitting your ISP? Or did you just mean freedom of communication in a rhetorical sense? Because it's not hitting the disks in their mail spool, nor are the sender and receiver checked against any policy databases. And if you will trust an ISP to deliver port 25 packets then why wouldn't you trust them to deliver email messages? Because the packets are an order of magnitude easier to do than e-mail, and the orders only keep rising when the number of subscriber rises. IP service is ubiquitous, your proposal would make an important service running on top of it not anymore. -- Niels. -- The idle mind is the devil's playground
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
Michael, Whether you like it or not, SPAM is the problem. There are legitimate uses of anonymous email. I, for one, think that a web of mail peering agreements would be detrimental to the situation, not helpful. Yes, people should have the option of authenticating emails they send, and, end users should have the option of rejecting unauthenticated messages. That's all there today. There's still lots of work to do on the UI and many improvements to be made in the smooth interoperation of the various standards, but, the base capabilities exist. As an example, I run a mail server for a number of non-profit organizations. I do this for free. It runs on the mailserver I maintain for my household. I'm able to do that because I'm not having to pay someone for an email peering agreement, but, instead, am able to deliver messages directly to the MX of the receiving party. Do you really think we need SMBGP? I think not. Owen pgpYtbwcTFtYB.pgp Description: PGP signature
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: [eweek article] Window of anonymity when domain exists, whois not updated yet
--On Wednesday, January 12, 2005 4:11 PM + [EMAIL PROTECTED] wrote: Right now I have freedom of communication. In your vision I would hand all that over to my ISP for the benefit of giving complete control over who can communicate with me to them. Perhaps you could explain to me just how you currently manage to get port 25 packets delivered to your friends without transitting your ISP? Or did you just mean freedom of communication in a rhetorical sense? Yes, my port 25 packets go through my ISP. However, TLS means that none of the SMTP conversation between my mailserver and my friends mailserver is visible to my ISP in an unencrypted form. Your system would require me to expose at least the envelope information to my ISP. Do you see the difference here? And if you will trust an ISP to deliver port 25 packets then why wouldn't you trust them to deliver email messages? I don't trust them to deliver port 25 packets. I expect them to deliver port 25 packets. Then, I authenticate the system at the other end using TLS and have an encrypted coversation. My ISP can see that there's encrypted data going through their network between our servers, but, they (at least theoretically) can't see what that data is. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpfaThFsltuT.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, 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: [eweek article] Window of anonymity when domain exists, whois not updated yet
on Wed, Jan 12, 2005 at 10:18:30AM -0800, Owen DeLong wrote: Michael, Whether you like it or not, SPAM is the problem. SPAM is a luncheon meat. UCE is one of the many problems, among the others being viruses/worms/trojans and their traffic (easily blocked by the proper upstream authority), outscatter/backscatter traffic (whether responding to joe jobs, viruses, or spammers trying to send their crud to virus-generated bogus addresses, etc.), bogus reports of forgery (cf. [EMAIL PROTECTED], for one example), C/R systems, autoresponders, callback mechanisms, et cetera. -- 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 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: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Wed, 12 Jan 2005 11:23:42 GMT, [EMAIL PROTECTED] said: I happen to believe that a web of email peering agreements is the best way to get us to the point where it is difficult for anyone to anonymously send email because they *MUST* relay it through an ISP who will not accept the email for relay unless they have authenticated the user. The X.400 concepts of ADMD= and PRMD= really caught on, didn't they? ;) Peering in a world of 64K ASNs, mostly basically static, is a lot different than peering in a world of 40 million plus .COMs, many in motion. Most of the time, we're lucky if the MX record points to the right place pgpwt3dX4b1iJ.pgp Description: PGP signature
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!
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
But as article specifically mentions sending during the night and registration next morning that does seem to indicate eweek found out about no whois but with already registered domain, i.e. see Could they simply be referring to the technique of sending spam at night with a URL to a non-existent domain? When everyone's NOC sees the spam for the first time and tries to get the website shut down, it's not there. Tickets are closed, and many people think someone else already had the site taken down. But, first thing in the morning, the domain is registered just in time to accept the first queries from gullible customers eager to find out how to collect their lottery winnings. For a few hours, the spammers collect phone numbers and then spend the next few days running their telephone con. Rinse and repeat. When we make it too hard for legitimate businesses to use spam as a means of advertising their product, then only criminals will use spam. The arms race continues... --Michael Dillon
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
--- [EMAIL PROTECTED] wrote: When we make it too hard for legitimate businesses to use spam as a means of advertising their product, then only criminals will use spam. you can have my mailserver when you can pry it from my cold, dead datacenter... seriously, there have been various proposals ([ADV], etc) to facilitate legit UCE, but that hasn't slowed the arms race. How would you recommend that we make it easier for legit businesses? = David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Tue, Jan 11, 2005 at 10:14:35AM +, [EMAIL PROTECTED] wrote: But as article specifically mentions sending during the night and registration next morning that does seem to indicate eweek found out about no whois but with already registered domain, i.e. see Could they simply be referring to the technique of sending spam at night with a URL to a non-existent domain? When everyone's NOC sees the spam for the first time and tries to get the website shut down, it's not there. Tickets are closed, and many people think someone else already had the site taken down. I was always interested to see how many people are actually falling for these Spam messages. Did anybody here ever try to register such a domain, after the mass mailing started but before the spammer registers it? Just put a dummy page there and then throw the access.log into a bunch of loganalyzers after a few days. Nils
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Tue, 11 Jan 2005, David Barak wrote: seriously, there have been various proposals ([ADV], etc) to facilitate legit UCE, but that hasn't slowed the arms race. How would you recommend that we make it easier for legit businesses? Legit businesses do not use spam. The phrase Legit UCE is similar to Legit fraud or Legit theft. If legit businesses want to use SCE or solicited commercial email, then such email is expected to be received and welcomed by the recipient and by definition not spam. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Tue, 11 Jan 2005, Suresh Ramasubramanian wrote: and it is being abused - well, nanog found out about this a while back, but the popular press (read - eweek magazine) seems to have discovered it now, or at least think they've discovered it .. their idea of the situation is a bit skewed. ... http://www.eweek.com/article2/0,1759,1749328,00.asp One troublesome technique finding favor with spammers involves sending mass mailings in the middle of the night from a domain that has not yet been registered. After the mailings go out, the spammer registers the domain early the next morning. Well, spammers do sometimes register domains after mass mailing has already started. Its partial result of that spammer enterprises are no longer centralized and so one company that actually hosts websites that are being promoted is not necessarily same company that is doing mass mailing. Sometimes the order-taker spammer tells the mass-mailing spammer new domain to use for the spam compaign before domain is even registered - and while they expect to register it at the time mailing gets started their synronization may not be precize and in any case they actually prefer the first few people who receive such emails to not be able to get to the website (no whois and no dns - no chance to report it to hosting and quickly shut it down). But as article specifically mentions sending during the night and registration next morning that does seem to indicate eweek found out about no whois but with already registered domain, i.e. see http://www.mail-archive.com/nanog@merit.edu/msg28312.html Read NANOG archives - Verisign now allows immediate (well, within about 10 minutes) updates of .com/.net zones (also same for .biz) while whois data is still updated once or twice a day. That means if spammer registers new domain he'll be able to use it immediatly and it'll not yet show up in whois (and so not be immediatly identifiable to spam reporting tools) - and spammers are in fact using this feature more and more! -- William Leibzon Elan Networks [EMAIL PROTECTED]
