Re: [OpenBD] Re: CFSMTP Mail delivery

['Alan Holden' via Open BlueDragon]

A few observations for the third Alan ;-] This first is pure opinion, and has nothing to do with technology: I think it's a long-term disservice to advise a recipient 1) not to reply directly to a message, 2) to say that such replies will not be read OR 3) use a sending address like "no-reply@"- AND THEN to actually attempt to handle "crazy people responses" after all. Much like some bacteria which develops a resistance to antibiotics through the actions of many, those crazy people develop resistance to the warnings - guessing that their responses actually WILL be processed - and by every one of us who also says that we won't. Thanks for that. If you're going to admonish people not to reply, then IGNORE their replies, dag nabit! Next, most modern MTAs will process hard and soft bounces back to the "From:" address, but will route hard replies (user pressed a reply button) to the "Reply-To:" address placed in the message header. No need for programmatic  slight-of-hand on our end. Put the human address as a Reply-To. Last, when OpenBD reads messages out of our "bounce bucket" email account, legitimately bounced emails will be formatted with the daemon 400/500 message in the body, and the original message as an attachment. We peel off all the attachments and process those (they contain the original header, with the tasty trace variables we put in there when we first sent them). The FBL messages work the same way. That's all we've found necessary to maintain lists that keep the majors happy. We used to "read" the bounced message with some regex (to glean any emails that were literally cited), but found that it produced no better results than sticking with the attachments and ignoring the rest. I suppose we could forward any messages in the bounce bucket - that contained NO attachment - to some human eyeballs; but that would run counter to my rant above. Plus it would lead clients to think that we can catch and forward 100% of them. Finally, if users are self-subscribing to your list under opt-in compliance, it is NOT a good idea for someone to correct typos or process "my new email is" replies. The bad entry is going to die, and the user will likely replace it soon. If you correct or update bad ones, then users will have multiple good records in there, get angry getting multiple messages, and become a support hassle. I'm happy there are others out there who use OpenBD to process mail. It's got quirks, but works pretty reliably in a tight space. Al Holden On 10/1/2015 11:07 AM, a...@ddmg.net wrote: 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 openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.