I worked a couple of years ago for a company that makes 'emarketing' software, and I managed the company's ASP for that software.
Most of the emails we sent out we're from internal, registered customers of the company. I would call these 'opt-in' emarketing messages that ranged from pitches to buy new or upgrade products, customer satisfaction surveys and automated replies for visiting a website and signing up.
There were, on the other hand, spammers. That is the only way to describe the quality of the emails they sent out. When I could query their databases and find email addresses of 'abuse@someisp.com' and other, similar non-customer addresses, there is no other way to classify it.
In either case, we never tried to hide or run away. We always used real email addresses and kept the same domain names. So, my challenges were, "How to I keep the 'good' customers from impacting the 'bad' customers?" I dealt a lot with CAUSE, the MAPS RBL and other organizations to keep the emails flowing.
So, here is my question: How do you, at the ISP level, differentiate between legitimate email marketing and Spam?
Now that I have thought about this some more, this doesn't make a fricking sense at all!!
What is the deal with having to rewrite apps to support a new file system? I thought the whole idea in MS developing Windows was to put an abstraction layer between the applications and 'what lies beneath'. The reason for doing this was to beat Lotus and Wordperfect, both of which had superior printer drivers in the DOS versions of their software.
So now MicroSloth wants to turn this around. The whole idea behind installable filesystems and an abstraction layer was to protect the application developer for having to deal with those types of details be presenting a uniform API to different resources. Maybe I am just being naïve, but this smacks of 'forced upgrades' to me. Bah!
Anyone remember the way that the GUI in OS/2 (Workplace Shell) would store store extended attributes of the WPS objects in the FS? I know that HPFS was far from a 'object file system', but once again, this sounds a lot like 'Windows 200x = OS/2 2.0'.
Slashdot Mirror
I worked a couple of years ago for a company that makes 'emarketing' software, and I managed the company's ASP for that software.
Most of the emails we sent out we're from internal, registered customers of the company. I would call these 'opt-in' emarketing messages that ranged from pitches to buy new or upgrade products, customer satisfaction surveys and automated replies for visiting a website and signing up.
There were, on the other hand, spammers. That is the only way to describe the quality of the emails they sent out. When I could query their databases and find email addresses of 'abuse@someisp.com' and other, similar non-customer addresses, there is no other way to classify it.
In either case, we never tried to hide or run away. We always used real email addresses and kept the same domain names. So, my challenges were, "How to I keep the 'good' customers from impacting the 'bad' customers?" I dealt a lot with CAUSE, the MAPS RBL and other organizations to keep the emails flowing.
So, here is my question: How do you, at the ISP level, differentiate between legitimate email marketing and Spam?
Now that I have thought about this some more, this doesn't make a fricking sense at all!!
What is the deal with having to rewrite apps to support a new file system? I thought the whole idea in MS developing Windows was to put an abstraction layer between the applications and 'what lies beneath'. The reason for doing this was to beat Lotus and Wordperfect, both of which had superior printer drivers in the DOS versions of their software.
So now MicroSloth wants to turn this around. The whole idea behind installable filesystems and an abstraction layer was to protect the application developer for having to deal with those types of details be presenting a uniform API to different resources. Maybe I am just being naïve, but this smacks of 'forced upgrades' to me. Bah!
Anyone remember the way that the GUI in OS/2 (Workplace Shell) would store store extended attributes of the WPS objects in the FS? I know that HPFS was far from a 'object file system', but once again, this sounds a lot like 'Windows 200x = OS/2 2.0'.
I loved the WPS. *sniff*