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.
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.
On 06/28/2016 08:04 PM, John C Klensin wrote:
Chip,
Richard is correct, but it is more than that.
Short answer: no, not really, however...
Longer answer below.
--On Tuesday, June 28, 2016 11:18 -0400 Chip
<[email protected]> wrote:
I know this question is not specifically germane to Exim but
everyone on this list has extensive experience with bouncing
policies.
If a receiver of campaign emails (that promotes itself as an
email security service) sends bounces to "reply-to" rather
than "bounces-to" as a policy despite bounces-to present in
all campaign emails headers, would this be considered a
violation of RFCs?
RFC 5321 (the SMTP spec) and its predecessors are organized and
specified around the notion of handling undeliverable messages
based on envelope information, alone, i.e. the argument to the
MAIL command. An MTA should not be looking at header fields at
all, whether they "reply-to:", "bounces-to:", or "trash-bin-at:"
(I just made the last one up). Strictly speaking, an MTA that
pays any attention to those headers in deciding where to send a
bounce message is in violation of the spec.
Now, in that conceptual model, if the message is delivered to
you, you open it in an MUA and decide to do something with it,
that doesn't have anything to do with "bouncing" the message
(which is normally considered an MTA function, as above). It is
common for you to be able to do things that we normally call
"replying" or "forwarding", but neither those terms nor the
related operations are really standardized: you can do whatever
you like with the message and then send the result wherever you
like, including according to your interpretation of whatever
header or body material seems relevant to you.
And, if there is a filtering program that acts as an automated
MUA on your behalf, the same answer applies: as far as the
standards are concerned, you can have it do whatever you find
appropriate and/or amusing based on whatever information to
which it/you choose to pay attention.
Does that help?
john
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
