| |||||||||||||||||||||||||||||||
|
> On July 24, 2007 at 05:43PM steeeeeveee wrote: > > > >> If I would be the dictator of mail, then I would prevent every one >> to send mails with stupid noreplay@ addresses. But unfortunately I have >> not that power and often I must do whatever the customer wants. I can >> try to educate them but some of them you can not educate. They don't >> listen. They want their newsletter coming from a non valid email >> address. They need it! They cry for it. They don't care if all of the >> headers are faked. They even don't understand what a header is. The >> only thing they know is: They want this newsletter and I should not >> prevent this newsletter from entering into THEIR domain. >> > > > The bottom line is that these customers are paying for a service. As > such, they are entitled to a service that meets their needs, not one > that some arbitrary dictator deems acceptable. The solution is simple, > ā la the 'basic' business model for instance. > > 1) Take the customers money and supply them with the services they > desire. > > 2) Don't accept money from the client thus allowing you to impose your > will. > > just because customers want their newsletter doesn't mean you can send "bad" mail. The problem is that you need to think of exceptinal cases: - what if the address does not exist anymore? In "normal" MLs, user gets unsubscribed after some number/duration of bounces. and this is generally automated. - what if the subscriber has left the company, and the address cannot be removed because it receives important mail? In "normal" MLs, it is easy to send an unsubscribe request using the user's address. some lists include infos on how to unsubscribe. others obey a standard model (-unsubscribe, ...etc). The problems really happen when - the mktg dept ask a developer to setup a newsletter UI on their webserver or whatever. - email is relayed by the local MTA, where abuse and postmaster are handled by sysadmin, who has no idea how the newsletter is managed - worst: lists of users are shared as excel sheets. go get them updated! ... etc. noreply is a valid address. The problem is not with this. If the messages contain information that will easily guide you to get an address unsubscribed, then it's ok. otherwise, we want a channel to get in touch with someone. I mean a human. a web page that shows "php error in ./inc/.... blah blah" or "sql error in ..." just drive me mad. I too can setup a spam site, claim that you can unsubscribe and create a program to issue fake errors !
| ||||||||||||||||||||||||||||||
© 2004-2008 readlist.com