Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Bounce handling is non-trivial as you need to deal with a lot of different servers and responses. This includes those servers that are misconfigured and bounces because your email/host/IP has been blacklisted / spam-scored. And there are tons of bounces because of "out of office" auto-replies.</p> <p>A simple solution I know is to put own headers into the message that identify the receiver address and the concrete sending (a token). When it bounces, the bounce can be verified based upon this.</p> <p>Another solution is to encode additional information into the sender address and parse it accordingly for bounces. For this you need to know about how email works, which generally is useful if you need with bounces.</p> <ul> <li><a href="https://stackoverflow.com/q/1011714/367456">Bounce Email handling with PHP?</a></li> <li><a href="https://stackoverflow.com/q/204910/367456">Tool for parsing SMTP logs that finds bounces</a></li> <li><a href="https://stackoverflow.com/q/565504/367456">How to check if an email address exists without sending an email?</a></li> <li><a href="https://stackoverflow.com/q/2667620/367456">Specifying the bounce-back address for email</a></li> </ul> <p>There is some great answer here on SO (but I haven't found it for this answer) that goes into many details on the topic. If I find it, I'll add it.</p> <p>The general point is, that I don't know about many PHP based tools to deal with bounces, I know PHPList (PHP components for mailinglist handling) has something in their repository:</p> <ul> <li><a href="https://web.archive.org/web/20120616192549/http://docs.phplist.com/PhpListConfigBounces" rel="nofollow noreferrer">Settings for handling bounces (last valid snapshot)</a> (<em>latest equivalent:</em> <a href="https://www.phplist.org/manual/ch040_bounce-management.xhtml" rel="nofollow noreferrer">Bounce Management - PHPList Manual</a>)</li> </ul> <p><strong>Edit:</strong> The related question with the very informative answer is:</p> <ul> <li><a href="https://stackoverflow.com/q/3905734/367456">How to send 100,000 emails weekly?</a></li> </ul> <p><strong>Edit:</strong> It's not much, just some links:</p> <blockquote> <p>I am wondering why there is no standard in email bouncing that allows you easily to identify bounces and the bounce reason - or is there? (like a RFC)</p> </blockquote> <p>There is <a href="http://tools.ietf.org/html/rfc3834" rel="nofollow noreferrer">RFC3834 - Recommendations for Automatic Responses to Electronic Mail</a> which go updated by <a href="http://tools.ietf.org/html/rfc5436" rel="nofollow noreferrer">RFC5436 Sieve Notification Mechanism: mailto</a>.</p> <p>Bouncing is also discussed in part in <a href="http://tools.ietf.org/html/rfc5321" rel="nofollow noreferrer">RFC5321 Simple Mail Transfer Protocol</a>, which clearly gives a reason that an MTA must report back if a message can not be delivered.</p> <p>The main problem is that the bounce-address (the sender) can not be verified in SMTP, so sending a bounce message bears the problem that it probably goes to a wrong person (Backscatter Spam).</p> <p>A relyable mailer therefore not only checks for bounces but does more with SMTP to gain a certain level of quality, see:</p> <ul> <li><a href="http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation" rel="nofollow noreferrer">Bounce Address Tag Validation (BATV)</a></li> <li><a href="http://en.wikipedia.org/wiki/Sender_Policy_Framework" rel="nofollow noreferrer">Sender Policy Framework (SPF)</a></li> </ul> <p>The whole Wikipedia page of the <a href="http://en.wikipedia.org/wiki/Non_delivery_report" rel="nofollow noreferrer">Non delivery report</a> might be interesting for a first view on the picture.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload