CiviCRM Community Forums (archive)

I currently have an unattended catch-all email address (bounce@mydomain.org) set-up to process bounces from mass mailings. The obvious problem with this set up is that if someone sends an email to an invalid address at mydomain.org, the don't receive any feedback (e.g., a standard delivery status notification). The email just disappears into a blackhole. For all the user knows, their email was received by someone and we're just ignoring them.

I mentioned this problem over in another post (http://forum.civicrm.org/index.php/topic,18414.0.html) but did not receive a response. So, I decided to whip up a quick n dirty modification to the EmailProcessor.php script to implement my desired functionality. The modified code is as follows, starting from line 173 of EmailProcessor.php.

// get $replyTo from either the Reply-To header or from From
// FIXME: make sure it works with Reply-Tos containing non-email stuff
$replyTo = $mail->getHeader('Reply-To') ? $mail->getHeader('Reply-To') : $mail->from->email;
               
// if $matches is empty, this email is not CiviMail-bound
if (!$matches) {
    $store->markIgnored($key);
       
    // TODO: use a configured email address from the Civi database, or do-not-reply@domain
   $text = "Your message was received by an unattended mailbox. Please check the email address for typos and try resending your message.\n\n".
                "If you still have trouble, send a message to admin@mydomain.org\n\n".
                "-----Original Message-----\n".
                "From: ".ezcMailTools::composeEmailAddress($mail->from)."\n".
                "To: ".ezcMailTools::composeEmailAddresses($mail->to,80)."\n".
                "Date: ".date(DATE_RFC822,$mail->timestamp)."\n".
                "Subject: ".$mail->subject."\n\n";

    if (isset($mail->body)) {
        if ($mail->body instanceof ezcMailText) {
            $text .= $mail->body->text;
        } else if ($mail->body instanceof ezcMailMultipart) {

            switch ($mail->body->multipartType( )) {
                case 'alternative':
                case 'digest':
                case 'mixed':
                    $parts = $mail->body->getParts();
                    break;
                case 'related':
                    $parts = $mail->body->getMainPart();
                    break;
                case 'report':
                default:
                    // probably a delivery status notification, so just skip it
                    continue;
            }

            foreach ($parts as $part) {
                if (isset($part->subType) and $part->subType == 'plain') {
                    $text .= $part->text;
                    break;
                }
            }
        }
    }

    // TODO: it might be nice to send this as multipart/report in order to make it a delivery status notification
                   
    $response = ezcMailTools::replyToMail($mail, new ezcMailAddress( 'bounce@mydomain.org', 'My Domain' ),REPLY_SENDER,"[Autoresponse] Re: ");
    $response->body = new ezcMailText($text);

    // TODO: use outgoing email settings from Civi?
    $transport = new ezcMailMtaTransport();
    $transport->send( $response );

    continue;
}
I'm not sure if this is the best way to do things, seeing as I'm neither a PHP expert nor a CiviCRM expert nor a mail protocol expert, but it seems to get the job done. I'm open to suggestions on how to improve the script. If anyone thinks this functionality would be useful for others, I would be willing to work on it a little bit to make it suitable for inclusion in a future release.

Yeah, unfortunately my host doesn't support subaddressing. I would love to use the + notation if I could, though.

I did consider setting up a dedicated Gmail account for this purpose, but then the reply-to address on all of our outgoing emails would be user+[subaddress]@gmail.com. Or am I wrong about that? I just generally feel that having all emails originate from our domain projects a more professional image.

I see your point about the blacklisting though. Honestly, I had not considered that aspect. However, I still don't think it is good practice to silently drop undeliverable messages. This is even touched upon explicitly in RFC 5231 (http://tools.ietf.org/html/rfc5321, see Section 6.2)

As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice. However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned. If silent message-dropping is misused, it could easily undermine confidence in the reliability of the Internet's mail systems. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate.

I think the best option in this case -- i.e., when a catchall address is required because subaddressing isn't supported -- is to extend the script to actually create a multipart/report delivery status notification (as opposed to a standard message) as the auto-response. The ezcMail classes do seem to support this functionality.

My hope is that delivery status notifications with standard status codes would not land you on a blacklist. Otherwise, most enterprise SMTP servers that I have used would present problems!

It is definitely a difficult tradeoff. Pretend that you're ignoring your constituent's messages (allow backscatter bounces), or look like you never contact them (accept possibility of blacklist).

You don't have to, get a working email server that handle the + notation. There is a technical option to make it work even without it, but it would need founding. If you could mih...

This being said, your reply to doesn't have to go to the bounce email, update to the latest version and don't track replies, should work

In your opinion, would enabling SPF lessen the chance of ending up on a blacklist due to backscatter from your domain? Or are the two concepts completely orthogonal?

That's to avoid others to send an email as you, here we are taking about your IP address sending. SPF is good practice and you will benefit from it though.