--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.
