Re: [exim] Is not honoring bounces-to violation of RFC?

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
<jeffschips@???> 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