I can guarantee you this is far from perfection. More probably, as I
just checked, the return-path always matches the bounces-to, so I'm
guessing the mailing campaign software put that bounces-to in there to
cover all bases.
On 06/28/2016 09:24 PM, John C Klensin wrote:
>
> --On Tuesday, June 28, 2016 20:55 -0400 Chip
> <jeffschips@???> wrote:
>
>> Yes that's very useful. Thanks.
>>
>> I just find it interesting that of the millions of legitimate
>> non-spammy, double-opt in emails I've sent out over the last
>> several years, all with bounces-to header included, not 1 and
>> I mean not one (1) which bounced back bounced back to the
>> reply-to, envelope-header or return-path or wherever the RFC
>> said it should bounce back to: All of them with the exception
>> of this recent company startup claiming to be an email spam
>> elimination service, bounced back to bounces-to where
>> automation swiftly and correctly blacklisted that email.
> You asked what the specs required. The above is a different
> question. Let me give you a hint about what may be happening
> and what to look for. There are three pieces of the story.
>
> First, a true bounce message -- the sort of thing an MTA
> generates when a message is undeliverable -- that conforms to
> the specs has two properties: (i) it is sent to the envelope
> reverse path address of the incoming message because the MTA
> never sees any of the headers you are referring to (see earlier
> note) and (ii) its own envelope reverse path (the one in the
> MAIL command of the bounce (strictly Non-delivery for that case)
> message) doesn't show the address of the system doing the
> bouncing but instead is the special null return-path "<>". I
> can assure you that Exim, at least by default, does that
> correctly.
>
> Second, because of concerns about so-called blowback spam and/or
> malware hidden in apparent non-delivery notifications, there are
> a lot of systems out there that are configured to simply discard
> messages with null return paths or that reject (and hence
> discard) messages for which they cannot verify delivery to the
> reverse path (since there isn't one). The latter is typically a
> bug. The former, IMO, represents dubious judgment because it
> means that uses who send messages with, e.g., typographical
> errors in forward-pointing addresses don't find out that their
> messages were not delivered -- the delivery system tries to tell
> them, but their own systems discard the notification.
>
> Third and more generally, many anti-spam systems do things that
> violate the letter and/or intent of the email specs in the hope
> of efficiently disposing of more messages that might be spam.
> One of those things is sometimes to avoid sending out
> non-delivery messages at all. That is more or less the other
> end the process in which a system that receives such messages
> discards them, as in the above. All I can say about those
> approaches is that they involve tradeoffs and one should be
> careful what one wishes for.
>
> However, if you are never seeing a non-delivery message, either
> you have achieved perfection and never send a message to an
> address that considers it undeliverable or you should look to
> your own systems to figure out where the non-delivery messages
> are being discarded or blocked.
>
> john
>
>
>
>> It is rather difficult to automate the blacklisting of dead,
>> bounced email addresses when the bounce report goes back to a
>> standard in-box reply-to or envelope-header inbox since the
>> bounce-to address is specifically designed to handle removal
>> of dead emails, and, more importantly the reply-to and
>> envelope-to are intentionally FOR a real person to reply to
>> the campaign email and develop correspondence with a real
>> person, not an automated script.
>>
>> It's very possible the nitty-gritty engineering details of
>> this is above my pay grade I will admit that.
>
>
>
>
