Dyn bounce processing improvement

[Lakjin]

Dyn treats complaints and unsubscribed users (via list-unsubscribe) as a hard bounce (i.e. Dyn adds users that complain or unsubscribe to suppression list). Therefore, I've changed processDyn to the following:

 if ($event == 'bounce') {
            $bounceLog = new CampaignBounceLog();
            $bounceLog->campaign_id     = $campaign->campaign_id;
            $bounceLog->subscriber_id   = $subscriber->subscriber_id;
            $bounceLog->message         = $bounceRule;
            $bounceLog->bounce_type     = $bounceType == 'soft' ? CampaignBounceLog::BOUNCE_SOFT : CampaignBounceLog::BOUNCE_HARD;
            $bounceLog->save();

            if ($bounceLog->bounce_type == CampaignBounceLog::BOUNCE_HARD) {
                $subscriber->addToBlacklist($bounceLog->message);
            }
            Yii::app()->end();
        }
       
        if ($event == 'complaint') {
            $bounceLog = new CampaignBounceLog();
            $bounceLog->campaign_id     = $campaign->campaign_id;
            $bounceLog->subscriber_id   = $subscriber->subscriber_id;
            $bounceLog->message         = 'complained';
            $bounceLog->bounce_type     = CampaignBounceLog::BOUNCE_HARD;
            $bounceLog->save();

            if ($bounceLog->bounce_type == CampaignBounceLog::BOUNCE_HARD) {
                $subscriber->addToBlacklist($bounceLog->message);
            }
            Yii::app()->end();
        }

        if ($event == 'unsubscribe') {
            if (Yii::app()->options->get('system.cron.process_feedback_loop_servers.subscriber_action', 'unsubscribe') == 'delete') {
                $subscriber->delete();
                Yii::app()->end();
            }

            $subscriber->saveStatus(ListSubscriber::STATUS_UNSUBSCRIBED);

            $trackUnsubscribe = CampaignTrackUnsubscribe::model()->findByAttributes(array(
                'campaign_id'   => $campaign->campaign_id,
                'subscriber_id' => $subscriber->subscriber_id,
            ));

            if (!empty($trackUnsubscribe)) {
                Yii::app()->end();
            }

            $trackUnsubscribe = new CampaignTrackUnsubscribe();
            $trackUnsubscribe->campaign_id   = $campaign->campaign_id;
            $trackUnsubscribe->subscriber_id = $subscriber->subscriber_id;
            $trackUnsubscribe->note          = 'Unsubscribed via Web Hook!';
            $trackUnsubscribe->save(false);
           
            $email = $request->getQuery('email');
               
            $dynAPI = 'xxx';

            $ch = curl_init( 'https://api.email.dynect.net/rest/json/suppressions/activate?apikey='.$dynAPI.'&emailaddress='.urlencode($email) );
            $options = array(
                CURLOPT_RETURNTRANSFER => true,
                CURLOPT_SSL_VERIFYHOST => 0,
                CURLOPT_SSL_VERIFYPEER => 0,
                CURLOPT_HTTPHEADER => array('Content-type: application/json')
            );
            curl_setopt_array( $ch, $options );
           curl_exec($ch);

            Yii::app()->end();
        }

This code does two things different than the default MailWizz code:

(a) It treats complaints as hard bounces, to match Dyn treating complaints as hard bounces

(b) It pings Dyn suppression list to remove unsubscribed users off the suppression list, because unsubscribed users should not be on the suppression list in the first place -- they should just be unsubscribed

Wondering if MailWizz can have these changes incorporated in the next update?

One more thing. MailWizz really should authenticate postback URLs somehow, e.g. include an authentication key in postback URL and MailWizz only accepts commands if the authentication key is valid. Otherwise, if someone is able to figure out the id for a delivery server, they can easily send fake pings to MailWizz.

 

[twisted1919]

@Lakjin 0 I don't believe we should mark complaints as hard bounces in mailwizz for various reasons, they are complaints after all, so unsubscribe makes perfect sense as the action.
However, the second part, as to removing them from dyn suppression list makes sense, thus that is something that i have implemented as suggested.

One more thing. MailWizz really should authenticate postback URLs somehow, e.g. include an authentication key in postback URL

This really does not worth the effort. You have to guess too many params to send a fake request and even if you do, then the gain/loss is just to little that you can safely disregard it.

 

[Lakjin]

@Lakjin 0 I don't believe we should mark complaints as hard bounces in mailwizz for various reasons, they are complaints after all, so unsubscribe makes perfect sense as the action.

I agree with you -- complaints should only be unsubscribed not blacklisted. However, Dyn puts all complaints on suppression list and that stops emails from going there. So MailWizz should mimick the behavior.

However, the second part, as to removing them from dyn suppression list makes sense, thus that is something that i have implemented as suggested.

Great! So did you make it so unsubscribed users are removed from suppression list or complaint users as well? I don't agree that complaint users should be removed from suppression list. I'd rather have the safety net of blacklisting complaint users than have them continue to submit complaints against me.

This really does not worth the effort. You have to guess too many params to send a fake request and even if you do, then the gain/loss is just to little that you can safely disregard it.

I highly disagree. The params aren't too hard to guess and anyone malicious looking to screw your website can figure them out. Further, adding basic authentication isn't a lot of work. I'm thinking something simple like this:

http://post.back.url/?relevant-params=xyz&key=50bitkey

MailWizz would generate a 50bitkey for each delivery server and the postback call would include the 50bitkey. Whenever there is a ping to postback URL, MailWizz would check to make sure the 50bitkey matches the key stored in MailWizz database for that server.

It is very simple, yet helps avoid a lot of problems -- as long as the URL is kept safe and only given to legitimate ESPs and not shared online, no one can abuse postback calls.