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