From normalperson at yhbt.net Tue Aug 3 05:10:00 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 3 Aug 2010 09:10:00 +0000 Subject: [ANN] Rainbows! 0.96.0 - range support Message-ID: <20100803091000.GA3255@dcvr.yhbt.net> Rainbows! is an HTTP server for sleepy Rack applications. It is based on Unicorn, but designed to handle applications that expect long request/response times and/or slow clients. * http://rainbows.rubyforge.org/ * rainbows-talk at rubyforge.org * git://git.bogomips.org/rainbows.git Changes: For concurrency models that use sendfile or IO.copy_stream, HTTP Range requests are honored when serving static files. Due to the lack of known use cases, multipart range responses are not supported. When serving static files with sendfile and proxying pipe/socket bodies, responses bodies are always properly closed and we have more test cases for dealing with prematurely disconnecting clients. Concurrency model specific changes: EventMachine, NeverBlock - * keepalive is now supported when proxying pipes/sockets * pipelining works properly when using EM::FileStreamer * these remain the only concurrency models _without_ Range support (EM::FileStreamer doesn't support ranges) Rev, RevThreadSpawn, RevThreadPool - * keepalive is now supported when proxying pipes/sockets * pipelining works properly when using sendfile RevThreadPool - * no longer supported under 1.8, it pegs the CPU at 100%. Use RevThreadSpawn (or any other concurrency model) if you're on 1.8, or better yet, switch to 1.9. Revactor - * proxying pipes/sockets with DevFdResponse is much faster thanks to a new Actor-aware IO wrapper (used transparently with DevFdResponse) * sendfile support added, along with Range responses FiberSpawn, FiberPool, RevFiberSpawn - * Range responses supported when using sendfile ThreadPool, ThreadSpawn, WriterThreadPool, WriterThreadSpawn - * Range responses supported when using sendfile or IO.copy_stream. See the full git logs for a list of all changes. -- Eric Wong From normalperson at yhbt.net Tue Aug 3 05:18:47 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 3 Aug 2010 09:18:47 +0000 Subject: [ANN] socket_dontwait - socket methods using MSG_DONTWAIT and more Message-ID: <20100803091847.GC3255@dcvr.yhbt.net> This library is a drop-in replacement that reimplements several IO methods with replacements using MSG_DONTWAIT for BasicSocket. This allows us to avoid unnecessary system calls and GVL bouncing. * http://bogomips.org/socket_dontwait/ * rainbows-talk at rubyforge.org * git://git.bogomips.org/socket_dontwait.git Reports of performance differences with and without this library loaded would be greatly appreciated! Feel free to email me privately if you're shy, too. HTML mail will be mercilessly deleted :P The rest of the README below: We've reimplemented the +readpartial+, +read_nonblock+, +write_nonblock+, +read+ and +write+ instance methods normally inherited from the IO class directly into BasicSocket with socket-specific system calls and flags. This library is only intended for Ruby 1.9 and will not build with other versions of Ruby. This only supports operating systems with the non-POSIX MSG_DONTWAIT flag for send(2) and recv(2) syscalls. This library is considered EXPERIMENTAL. If successful, we'll see about getting them integrated into the standard Ruby socket library. == Features * Avoid use of fcntl(2) to set O_NONBLOCK in favor of MSG_DONTWAIT when using non-blocking I/O. We _unset_ O_NONBLOCK if we need to block and release the GVL instead of relying on select(2). * Avoids select(2) entirely in favor of blocking I/O when the GVL is released. This allows using file descriptor numbers higher than 1023 without overflowing select(2) buffers. * BasicSocket#read uses recv(2) with MSG_WAITALL to avoid extra system calls for larger reads. * Thread and signal-safe, releases the GVL for all blocking operations and retries if system calls are interrupted. * Includes a 1.9.1-specific workaround to preserve errno after reacquiring the GVL. This is {fixed}[http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=27401] in newer versions of Ruby. * Falls back to line-buffered IO if needed (not recommended). == Bugs/Caveats * We ignore taint/$SAFE checks, we'll support it if there's demand, but we doubt there is... * Does not support 1.9 encoding filters. 1.9 defaults all sockets to Encoding::BINARY anyways, so this should not be noticeable to code that leaves socket encodings untouched. * Does not support write buffering in userspace. Ruby defaults all sockets to "IO#sync = true", anyways so this does not affect code that leaves the default setting untouched. * Avoid using line-buffered IO on sockets (IO#gets, IO#each_line), nearly all of the features of this library are cancelled out when the line-buffering fallback is used. == Install If you're using a packaged Ruby distribution, make sure you have a C compiler and the matching Ruby development libraries and headers. You need Ruby 1.9 to install socket_dontwait. Previous versions of Ruby will NOT be supported. If you use RubyGems: gem install socket_dontwait Otherwise grab the latest tarball from: http://bogomips.org/socket_dontwait/files/ Unpack it, and run "ruby setup.rb" == Development You can get the latest source via git from the following locations: git://git.bogomips.org/socket_dontwait.git git://repo.or.cz/socket_dontwait.git (mirror) You may browse the code from the web and download the latest snapshot tarballs here: * http://git.bogomips.org/cgit/socket_dontwait.git (cgit) * http://repo.or.cz/w/socket_dontwait.git (gitweb) Inline patches (from "git format-patch") to the mailing list are preferred because they allow code review and comments in the reply to the patch. We will adhere to mostly the same conventions for patch submissions as git itself. See the Documentation/SubmittingPatches document distributed with git on on patch submission guidelines to follow. Just don't email the git mailing list or maintainer with socket_dontwait patches. == Contact/Bug Reports/Feedback/Patches/Pull-Requests This was originally created for the Rainbows! project (but may be used by others), so we'll reuse their mailing list at {rainbows-talk at rubyforge.org}[mailto:rainbows-talk at rubyforge.org]. -- Eric Wong From normalperson at yhbt.net Mon Aug 9 18:44:01 2010 From: normalperson at yhbt.net (Eric Wong) Date: Mon, 9 Aug 2010 15:44:01 -0700 Subject: [ANN] socket_dontwait - socket methods using MSG_DONTWAIT and more In-Reply-To: <20100803091847.GC3255@dcvr.yhbt.net> References: <20100803091847.GC3255@dcvr.yhbt.net> Message-ID: <20100809224401.GA12996@dcvr.yhbt.net> Eric Wong wrote: > This library is considered EXPERIMENTAL. If successful, we'll see about > getting them integrated into the standard Ruby socket library. I've been running socket_dontwait for a few days now with real traffic (and thus unreliable and slow clients) and haven't noticed anything wrong. No crashes, corrupted data, nor fires :) In synthetic benchmarks, I've seen a ~3-4% performance improvement with small responses (<= 4K) due to the reduction of syscalls but nothing measurable with real traffic (which varies a lot and doesn't even come close to saturating the machines). -- Eric Wong From john at brightbox.co.uk Tue Aug 10 18:23:12 2010 From: john at brightbox.co.uk (John Leach) Date: Tue, 10 Aug 2010 23:23:12 +0100 Subject: streaming input for large requests Message-ID: <1281478992.8692.15.camel@dogen> Hi, I'm looking to be able to get access to the request body as it is available on the socket, so I can process uploads on the fly, as they stream in. The docs suggest this is possible with rack.input: "Exposes a streaming ?rack.input? to the Rack application that reads data off the socket as the application reads it (while retaining rewindable semantics as required by Rack). This allows Rack-compliant apps/middleware to implement things such as real-time upload progress monitoring." But to be rewindable, I'm assuming they're being stored somewhere? I'd like to be able to handle huge request bodies bit by bit without having them written to disk (or worse, stored in ram!). Is there some way to do this? Thanks, John. From normalperson at yhbt.net Tue Aug 10 19:25:27 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 10 Aug 2010 16:25:27 -0700 Subject: streaming input for large requests In-Reply-To: <1281478992.8692.15.camel@dogen> References: <1281478992.8692.15.camel@dogen> Message-ID: <20100810232527.GA14486@dcvr.yhbt.net> John Leach wrote: > Hi, > > I'm looking to be able to get access to the request body as it is > available on the socket, so I can process uploads on the fly, as they > stream in. Hi John, Cool! If you need some example code, you should check out upr, http://upr.bogomips.org/ Sadly the demo machine is down, but the one application I helped somebody write (on a private LAN somewhere) still works well :) There's also the test/examples in the Rainbows! source tree: t/sha1*.ru t/content-md5.ru > But to be rewindable, I'm assuming they're being stored somewhere? I'd > like to be able to handle huge request bodies bit by bit without having > them written to disk (or worse, stored in ram!). Is there some way to > do this? Yes, we store uploads to an unlinked temporary file if the body is larger than 112 Kbytes (this threshold was established by Mongrel back in the day). Rack currently requires rewindability, but this requirement will most likely be optional in Rack 2.x, and we'll update our code to match, then. Meanwhile, you can either: 1. Write a module to disable writes to tmp for the Unicorn::TeeInput class (or monkey patch it) it. 2. Without loading Rack::Lint (or anything that wraps env["rack.input"]): Redirect the temporary file to /dev/null: input = env["rack.input"] if input.respond_to?(:tmp) tmp = input.tmp # StringIO is used for bodies <112K, can't reopen those tmp.respond_to?(:reopen) and tmp.reopen('/dev/null', 'wb') end -- Eric Wong From john at brightbox.co.uk Wed Aug 11 04:54:48 2010 From: john at brightbox.co.uk (John Leach) Date: Wed, 11 Aug 2010 09:54:48 +0100 Subject: streaming input for large requests In-Reply-To: <20100810232527.GA14486@dcvr.yhbt.net> References: <1281478992.8692.15.camel@dogen> <20100810232527.GA14486@dcvr.yhbt.net> Message-ID: <1281516888.8692.49.camel@dogen> On Tue, 2010-08-10 at 16:25 -0700, Eric Wong wrote: > Yes, we store uploads to an unlinked temporary file if the body is > larger than 112 Kbytes (this threshold was established by Mongrel back > in the day). > > Rack currently requires rewindability, but this requirement will > most likely be optional in Rack 2.x, and we'll update our code > to match, then. > > Meanwhile, you can either: > > 1. Write a module to disable writes to tmp for the Unicorn::TeeInput > class (or monkey patch it) it. > > 2. Without loading Rack::Lint (or anything that wraps env["rack.input"]): > Redirect the temporary file to /dev/null: > > input = env["rack.input"] > if input.respond_to?(:tmp) > tmp = input.tmp > # StringIO is used for bodies <112K, can't reopen those > tmp.respond_to?(:reopen) and tmp.reopen('/dev/null', 'wb') > end > thanks for the detailed response Eric. I'll give this a go. John. From gratefull at sutiamadrid.nom.es Wed Aug 11 12:08:29 2010 From: gratefull at sutiamadrid.nom.es (EURO MILLION INTERNATIONAL LOTTERY ) Date: Wed, 11 Aug 2010 16:08:29 -0000 Subject: CONGRATULATIONS!! YOU HAVE JUST WON 515,810 EUROS IN EURO MILLION INTERNATIONAL ANNUAL LOTTERY PROGRAM Message-ID: SPANISH EURO MILLION INTERNATIONAL LOTTERY COMMISSION FROM THE DESK OF THE PRESIDENT PRIZE AWARD DEPARTMENT C/ Lambllia frente 4 planta #26 , 22476, MADRID, SPAIN. 11-08-2010 Attn: Lucky Winner, We happily announce to you the final result on our EURO MILLION INTERNATIONAL ANNUAL LOTTERY PROGRAM. This result was initially delayed due to mix up of email addresses, the results were finally released on 10th August 2010. your email address [ rainbows-talk at rubyforge.org ] attached to TICKET NUMBERS : 21200560 with LUCKY NUMBERS : 41-6-76-13-45-8 which drew the BATCH NUMBER: EURO/1007/444/606/08 and WINNING REFERENCENUMBER: ESP/WIN/008/05/10/MA, which consequently won you the lottery in the Second category of the year 2010. NO TICKET WAS SOLD. You are therefore approved for a lump sum payment of 515,810 Euros (Five Hundred and Fifteen Thousand Eight Hundred and Ten Euros only) in cash. This is from a total cash prize of 4,642,290 Euros (Four million six hundred and forty two Thousand, two Hundred and ninety Euros Only) Shared among the nine international winners in this category. To avoid unnecessary delays on your winning prize, you are to contact the appointed agent directly for the immediate release of your winnings fund with the below details. TICKTET NUMBERS : 21200560 LUCKY NUMBERS : 41-6-76-13-45-8 BATCH NUMBER: EURO/1007/444/606/08 WINNING REFERENCE NUMBER: ESP/WIN/008/05/10/MA WINNING EMAIL : [ rainbows-talk at rubyforge.org ] 1) Your Full Name: 2) Your Telephone Number: 3) Your Mobile Number 4) Fax Number (If available) OCASO SEGURIDAD ESPANA S.A. MR. MARIANO FERNANDEZ BERMEJOU TEL: 00346,031,25674 FAX: 00349,176,93011 Email: ocasoseguridad at luckymail.com Congratulations once again from all our staff. Mrs. Paulina Domin Hanna (Lottery co-ordinator) Spanish Euro Million International Lottery Commission. From john at brightbox.co.uk Wed Aug 11 18:41:32 2010 From: john at brightbox.co.uk (John Leach) Date: Wed, 11 Aug 2010 23:41:32 +0100 Subject: streaming input for large requests In-Reply-To: <20100810232527.GA14486@dcvr.yhbt.net> References: <1281478992.8692.15.camel@dogen> <20100810232527.GA14486@dcvr.yhbt.net> Message-ID: <1281566492.25884.6.camel@dogen> On Tue, 2010-08-10 at 16:25 -0700, Eric Wong wrote: > John Leach wrote: > > Hi, > > > > I'm looking to be able to get access to the request body as it is > > available on the socket, so I can process uploads on the fly, as they > > stream in. > > Hi John, > > Cool! If you need some example code, you should check out upr, > http://upr.bogomips.org/ Sadly the demo machine is down, but the one > application I helped somebody write (on a private LAN somewhere) still > works well :) > > There's also the test/examples in the Rainbows! source tree: > > t/sha1*.ru > t/content-md5.ru > > > But to be rewindable, I'm assuming they're being stored somewhere? I'd > > like to be able to handle huge request bodies bit by bit without having > > them written to disk (or worse, stored in ram!). Is there some way to > > do this? > > Yes, we store uploads to an unlinked temporary file if the body is > larger than 112 Kbytes (this threshold was established by Mongrel back > in the day). > > Rack currently requires rewindability, but this requirement will > most likely be optional in Rack 2.x, and we'll update our code > to match, then. > > Meanwhile, you can either: > > 1. Write a module to disable writes to tmp for the Unicorn::TeeInput > class (or monkey patch it) it. > > 2. Without loading Rack::Lint (or anything that wraps env["rack.input"]): > Redirect the temporary file to /dev/null: > > input = env["rack.input"] > if input.respond_to?(:tmp) > tmp = input.tmp > # StringIO is used for bodies <112K, can't reopen those > tmp.respond_to?(:reopen) and tmp.reopen('/dev/null', 'wb') > end > I knocked together a little test app to do this as you suggested, it works a treat: http://gist.github.com/519915 Thanks again Eric! John. # # This little test app generates SHA1 hashes for HTTP uploads on the # fly, without storing them on disk. # By John Leach (with help from Eric Wong) # # Start the server like this: # # rainbows -c rainbows.conf.rb rainbows-sha1.ru # # I've been testing this with Revactor, which requires Ruby 1.9 # # Use with the following rainbows.conf.rb: # # ENV['RACK_ENV'] = nil # we don't want lint to be loaded # worker_processes 2 # Rainbows! do # use :Revactor # client_max_body_size nil # end # # You can upload files like this: # # curl -v -T /path/to/a/file/to/upload http://localhost:8080/ # # You can upload infinite data to test concurrency like this: # # dd if=/dev/zero bs=16k | curl -v -T - http://localhost:8080/test.bin # # Spawn as many of these as you like :) You'll notice regular debug # output from the server telling you the upload progress of each # concurrent upload. # # If all is well, your disk space should not decrease during the # uploads and the ram usage of the server should not balloon. bs = ENV['bs'] ? ENV['bs'].to_i : 16384 require 'digest/sha1' use Rack::CommonLogger use Rack::ShowExceptions use Rack::ContentLength app = lambda do |env| # Tell all expect requests we're happy to accept /\A100-continue\z/i =~ env['HTTP_EXPECT'] and return [ 100, {}, [] ] input = env["rack.input"] if input.respond_to?(:tmp) tmp = input.tmp # Hack to prevent request being written to disk tmp.respond_to?(:reopen) and tmp.reopen('/dev/null', 'w+') end digest = Digest::SHA1.new recv_bytes = 0 last_time = Time.now.to_i last_recv_bytes = 0 req_id = rand(0xffff) while buf = input.read(bs) recv_bytes += buf.size digest.update(buf) if (recv_bytes / bs) % 10000 == 9999 time_diff = Time.now.to_i - last_time + 1 recv_bytes_diff = recv_bytes - last_recv_bytes speed = (recv_bytes_diff / time_diff) / 1024 recv_meg = recv_bytes / 1024 / 1024 msg = "req #{req_id}: #{recv_meg}M so far, (#{speed}k/s)\n" env['rack.errors'].write msg last_time = Time.now.to_i last_recv_bytes = recv_bytes end end [ 200, { 'Content-Type' => 'text/plain', 'SHA1' => digest.hexdigest, 'Received-Bytes' => recv_bytes.to_s }, [''] ] end run app From normalperson at yhbt.net Sun Aug 15 21:40:04 2010 From: normalperson at yhbt.net (Eric Wong) Date: Mon, 16 Aug 2010 01:40:04 +0000 Subject: [PATCH] FAQ: update SSL section, add Pound Message-ID: <20100816014004.GA9041@dcvr.yhbt.net> Hi all, I just added Pound to the FAQ section. Does anybody have more experience with other HTTPS reverse proxy solutions and could recommend them? Pound has the advantage of coming with X-Forwarded-For support out-of-the-box. I haven't tested either for performance/scalability. Both use the thread-per-connection concurrency model, but Pound appears to use the default stack size (8M(!) on my NPTL systems) while stunnel sets the thread stack size to 64K (which I seem to recall was the minimum under LinuxThreads). Nowadays NPTL allows stack sizes as low as 16K (which is still high IMHO, but I also don't know how much stack OpenSSL uses). Those of you with more interest in HTTPS performance/scalability could try lowering stack sizes for Pound and perhaps submitting patches upstream. >From 2f0ac01589cdc9775f7a5668c4ac491712a9f1b1 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Mon, 16 Aug 2010 01:02:30 +0000 Subject: [PATCH] FAQ: update SSL section, add Pound Pound appears to work well in my limited testing with t/sha1.ru and "curl -T-" --- FAQ | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/FAQ b/FAQ index 5c4ea2c..7609d55 100644 --- a/FAQ +++ b/FAQ @@ -52,9 +52,14 @@ solution even if nginx will always outperform it in raw throughput. === How do I support SSL? -If you need a streaming "rack.input" to do upload processing within your -Rack application, then {stunnel}[http://stunnel.org/] is required. -Otherwise, nginx is a perfectly good reverse proxy. +If you need streaming "rack.input" to do on-the-fly upload processing +within your Rack application, then using an SSL proxy such as +{Pound}[http://www.apsis.ch/pound/] or {Stunnel}[http://stunnel.org/] is +required. Pound has built-in X-Forwarded-For support while Stunnel +requires a extra {patch}[http://haproxy.1wt.eu/download/patches/]. + +If you don't need streaming "rack.input", then nginx is a great HTTPS +reverse proxy. Refer to the {Unicorn FAQ}[http://unicorn.bogomips.org/FAQ.html] on how to ensure redirects go to "https://" URLs. -- Eric Wong From herzlichengluckwunsch15 at gmail.com Thu Aug 26 06:33:30 2010 From: herzlichengluckwunsch15 at gmail.com (GARCIA & JAVIER ASOCIADOS) Date: Thu, 26 Aug 2010 12:33:30 +0200 Subject: ATTENTION Message-ID: GARCIA & JAVIER ASOCIADOS Ramble Novas 121-20, 43004 Tarragon Catalonia, Spain Postal Address: Sucrsal 13-301 46021, Valencia Spain YOUR REF:SPE/327/010 26/8/2010 Firstly, I must solicit your confidence in this transaction; this is by virtue of its nature as being utterly confidential and top secret. Though I know that a transaction of this magnitude will make any one apprehensive and worried, but I am assuring you that all will be well at the end of the day. Let me start by first introducing myself properly to you. It may surprise you receiving this letter from me, since there was no previous correspondence between us. My name is Barr Steve S. Wingan. a personal Attorney to Late Mr. Donka Humar purpose of contacting you is for you to help secure the funds left behind by my late client, to avoid it being confiscated or declared serviceable by the Bank Where this fund valued 7,500,000.00(Seven Million Five Hundred Thousand euro) deposited by my client before his death. This Bank has issued me a notice to contact the next of kin or the account will be declared unserviceable and the fund diverted to the Bank treasury, So far all my efforts to get a hold of someone related to this man has proved abortive. Hence, I have contacted you. I am actually asking for your consent to present you to the Bank as the Next of Kin/beneficiary of my late client fund. While the fund can be easily be transfer into your account. All the legal documentations to back up your claim as my client's Next of Kin I shall provided them. All I require is your honest cooperation to enable us achieve this transaction. I wish to point out that I want 20% of this money to be shared among the charity Organizations, while the remaining 80% is shared equally between us. This proposition is entirely risk free. I will use my position as the clients attorney to guarantee the successful execution of this transaction. If you are interested, please contact me via Email: stvstv29 at gmail.com upon your response, I shall then provide you with more details and relevant documents that will help you understand this transaction well. The intended transaction will be executed under a legitimate arrangement that will protect you from any infraction of the law. However, if this business proposition offends your moral ethics, do accept my sincere apology. If on the contrary you wish to achieve this goal with me, kindly get back to me with your interest for further explanation. Kindest Regards Barr. Steve .S. Wingan From normalperson at yhbt.net Sat Aug 28 16:06:52 2010 From: normalperson at yhbt.net (Eric Wong) Date: Sat, 28 Aug 2010 20:06:52 +0000 Subject: [ANN] Rainbows! 0.97.0 Message-ID: <20100828200652.GB17753@dcvr.yhbt.net> Changes: We now depend on Unicorn 1.1.3 to avoid race conditions during log cycling. This bug mainly affected folks using Rainbows! as a multithreaded static file server. "keepalive_timeout 0" now works as documented for all backends to completely disable keepalive. This was previously broken under EventMachine, Rev, and Revactor. There is a new Rainbows::ThreadTimeout Rack middleware which gives soft timeouts to apps running on multithreaded backends. There are several bugfixes for proxying IO objects and the usual round of small code cleanups and documentation updates. See the commits in git for all the details. * http://rainbows.rubyforge.org/ * rainbows-talk at rubyforge.org * git://git.bogomips.org/rainbows.git -- Eric Wong From johndodger at gmail.com Sun Aug 29 02:09:05 2010 From: johndodger at gmail.com (Fran Mcintyre) Date: Sun, 29 Aug 2010 11:39:05 +0530 (IST) Subject: ***BULK*** Healthcare/Business and Finance/Consumer/Professional Lists Message-ID: <20100829060905.D7C1A4A195E@mail.butp.org> Until Friday Aug 27 you can buy any list below for just $199 each, 3 for $299 or 5 for $399: All lists are 100% optin and are 6 months or newer. ** HEALTHCARE LISTS ** - Physicians (34 specialties) - 788k records, 17k emails, 200k fax numbers - Chiropractors - 108,421 total records * 3,414 emails * 6,553 fax numbers - Alternative Medicine - 1,141,602 total records with 36,320 emails and 38.935 fax numbers - Dentists - 164k records, 45k emails, 77k fax numbers - Veterinarians - 78,986 total records with 1,438?emails and 1,050?fax numbers - Hospitals - 23,747 Hospital Administrators in over 7,145 Hospitals (full contact info no emails) - National Health Service Corp Clinics - 1,300 total records with emails for government run free clinics - Nursing Homes - 31,589 Senior Administrators, 11,288 Nursing Directors in over 14,706 Nursing Homes (full contact info no emails) - Pharmaceutical Companies - Email only list 47,000 emails of pharma company employees - Physical Therapists - 125,460 total records with 5,483 emails and 4,405 fax numbers - Oncology Doctors - 2,200 records all with emails - US Surgery Centers - 85k records and 14k emails - Massage Therapists - 76,701 records and 8,305 emails - Acupuncturists - 23,988 records 1,826 emails - Medical Equipment Suppliers - 167,425 total records with 6,940 emails and 5,812 fax numbers - Mental Health Counselors - 283,184 records 7,206 emails - Visiting Nurses & RN's - 91,386 total records with 2,788 emails and 2,390 fax numbers - Optometrists - 63,837 records 2,015 emails - Psychologists - 272,188 records and 9,874 emails ** BUSINESS AND FINANCE LISTS ** - Hotels - 34,815 total records * 1,642 emails - Real Estate Agents - 1 million records with emails - American Business Email List - 2 million emails various businesses - US New Business Database - 4.8 million records all with emails - Manufacturers Database - 1,057,119 records with 476,509 emails - Financial Planners Database - 148,857 records all with emails - Finance and Money Professionals Database - 116,568 records all with emails ** CONSUMER LISTS ** - American Consumer Database - 300,000 records all with emails. - Credit Inquiries Database - 1 million Full Data Records all with emails - American Homeowners - 1 million Full Data Records all with emails ** PROFESSIONALS LISTS ** - USA Lawyers Database - 269,787 records with 235,244 emails - Police and Sheriff Services - 42,987 records and 114 emails - Criminal Attorneys - 142,906 total records, 99,857 emails email me if you're interested: instantresults at gmx.com click this to stop getting these emails. please send an email to offthelist at gmx.com