Al, We do very similar to you do when it comes to sending email blasts. Biggest difference is that we currently simply set up a noreply box that is the sending from address and the client can log into that when/if they desire. The MTA we use is mostly postfix (I have a few older boxes that use sendmail from initial set up but all the new systems we deploy now use postfix).
What I'm working on now is a separate stand-alone system that in concept will work in conjunction with the different blast servers we have. So the concept is that the blast happens on the system it's located currently. We update the sending email address to be at a sub-domain of the clients primary domain. We route DNS MX record for that sub-domain to this new system box. We will have data entries per sending email such that this system will only accept mail designated to that sending email. All others are rejected - one of the primary reasons that we needed to get the cfcFilter to work properly. Once the system accepts the mail then we will do some checking on the subject and body to determine if the email is a bounce message or not. If it's a bounce message, then this system will connect to the appropriate blast system database and mark that email entry as "bounced" status, which will prevent the blast system from sending further messages. Similar to our 'remove me' feature but automated on the bounce. The blast system will have an added screen / report to show the client which emails have/are in a bounce status so they can easily update the record if need be (i.e. the address was typo'd and they can easily determine the resolution), or deleted from their blast system. The last thing is to handle those crazy folks that actually reply to the noreply emails. If the email is not a bounce email and it is from one of the clients blast emails, then we will strip off any CC or BCC or additional TO addresses (to prevent any spamming) and then forward or deliver the email to the client contact address. This way if one of their customers ask an important question then the client gets that email and can reply directly to that customer. I believe I can create one main system that will tie into all our separate blast systems - just have to have configurations for each blast system and it's datasource information. Should help us reduce bandwidth of continuing to send emails to bounced addresses, help the client keep their list clean and up-to-date and allow the client to still receive the random actual email communication from a customer. I'm other folks probably already have systems like this in place. That's how it should work... in theory lol. Hopefully in the next week or so I will have it running on one of the lists/blasts and we can start to see if it will work out properly. Thanks for all the input and help (both from this list/community in general and from folks that have helped on this particular issue). Alan -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
