Is not honoring bounces-to violation of RFC?

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Is not honoring bounces-to violation of RFC?

Chip-2
I know this question is not specifically germane to Postfix 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?

Reply | Threaded
Open this post in threaded view
|

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

Wietse Venema
Chip:
> I know this question is not specifically germane to Postfix 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?

RFCs are published at ietf.org, so I did an experiment:

        site:ietf.org bounces-to

Neither google.com nor bing.com produced any matches.

I guess that result speaks for itself, no?

        Wietse
Reply | Threaded
Open this post in threaded view
|

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

Chip-2
Okay I guess it does.  Meaning there are no standards for the way
emailers should respond to bounces?

On 06/28/2016 12:54 PM, Wietse Venema wrote:

> Chip:
>> I know this question is not specifically germane to Postfix 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?
> RFCs are published at ietf.org, so I did an experiment:
>
> site:ietf.org bounces-to
>
> Neither google.com nor bing.com produced any matches.
>
> I guess that result speaks for itself, no?
>
> Wietse
>

Reply | Threaded
Open this post in threaded view
|

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

Wietse Venema
Chip:
> Okay I guess it does.  Meaning there are no standards for the way
> emailers should respond to bounces?

According to RFC 5321, the definition of the Internet email protocol,
an undeliverable email message is returned to its MAIL FROM address,
and that return message is sent with the null MAIL FROM adress.
Undeliverable mail with the null MAIL FROM address is not returned.

That answers your question, but you probably meant something else.

        Wietse
Reply | Threaded
Open this post in threaded view
|

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

Noel Jones-2
In reply to this post by Chip-2
On 6/28/2016 12:12 PM, Chip wrote:
> Meaning there are no standards for the way
> emailers should respond to bounces?

bounces always go to the envelope sender, regardless of any
unrelated junk in the headers.



Reply | Threaded
Open this post in threaded view
|

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

Chip-2
In standard email campaign software like phplist, constantcontact,
mailchimp all of those popular email campaign software many of which use
Exim and are used literally by millions of email campaigners, the
bounces-to is where bounces are expected to be returned so that they can
be effectively removed from mailings and people don't' receive spam.  It
is an very important part of email campaigns and reduces by great
amounts the amount of spam that is manufactured.

Okay maybe it's not in RFC's but I would it would be at least a
recommendation that bounces can be routed back to bounces-to rather than
reply-to.  After all, why have the field at all if it's not used properly.




On 06/28/2016 01:51 PM, Noel Jones wrote:
> On 6/28/2016 12:12 PM, Chip wrote:
>> Meaning there are no standards for the way
>> emailers should respond to bounces?
> bounces always go to the envelope sender, regardless of any
> unrelated junk in the headers.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Noel Jones-2
Bounces go to the envelope sender, the address used in the SMTP MAIL
FROM command.

Not reply-to, nor bounces-to, nor any other address listed in a
header.

To control where bounces are returned, set the envelope sender.



  -- Noel Jones


On 6/28/2016 1:28 PM, Chip wrote:

> In standard email campaign software like phplist, constantcontact,
> mailchimp all of those popular email campaign software many of which
> use Exim and are used literally by millions of email campaigners,
> the bounces-to is where bounces are expected to be returned so that
> they can be effectively removed from mailings and people don't'
> receive spam.  It is an very important part of email campaigns and
> reduces by great amounts the amount of spam that is manufactured.
>
> Okay maybe it's not in RFC's but I would it would be at least a
> recommendation that bounces can be routed back to bounces-to rather
> than reply-to.  After all, why have the field at all if it's not
> used properly.
>
>
>
>
> On 06/28/2016 01:51 PM, Noel Jones wrote:
>> On 6/28/2016 12:12 PM, Chip wrote:
>>> Meaning there are no standards for the way
>>> emailers should respond to bounces?
>> bounces always go to the envelope sender, regardless of any
>> unrelated junk in the headers.
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

allenc
In reply to this post by Noel Jones-2
Mail-server refusals (as in NOQUEUE) are generated before the email body
is received - and will also be sent to the envelope sender.

On 28/06/16 18:51, Noel Jones wrote:
> On 6/28/2016 12:12 PM, Chip wrote:
>> Meaning there are no standards for the way
>> emailers should respond to bounces?
> bounces always go to the envelope sender, regardless of any
> unrelated junk in the headers.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Jim Reid
In reply to this post by Chip-2

> On 28 Jun 2016, at 19:28, Chip <[hidden email]> wrote:
>
> Okay maybe it's not in RFC's but I would it would be at least a recommendation that bounces can be routed back to bounces-to rather than reply-to.  After all, why have the field at all if it's not used properly.

No RFC defines a bounces-to email header. Or how an MTA or MUA should handle one. As a matter of fact, the only email-related RFC which contains the word “bounce” is RFC5355. Which is in the Experimental category. It uses “bounce" in the context of clients speaking UTF8SMTP to servers that don’t support this feature.

Here’s the relevant part of Section 4.4 of that RFC:

  Below are a few examples of possible <mailbox> representations.

      ...

      "DISPLAY_NAME" <non-ASCII@non-ASCII>
         ; UTF8SMTP but no ALT-ADDRESS parameter provided,
         ; message will bounce if UTF8SMTP extension is not supported

      <non-ASCII@non-ASCII>
         ; without DISPLAY_NAME and quoted string
         ; UTF8SMTP but no ALT-ADDRESS parameter provided,
         ; message will bounce if UTF8SMTP extension is not supported


If you think bounces-to has to be part of Internet email standards, feel free to write up a draft and submit it to the IETF.
Reply | Threaded
Open this post in threaded view
|

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

Chip-2
In reply to this post by allenc

I don't dispute any of what happens just saying that a company out there that advertises as their mission to eliminate spam and whom, they advertise, has access to 30 million MX records is sending bounces to the reply to or envelope sender whereas I'm just saying that ALL email campaign services allow and indeed suggest users to identity a specific sole purpose email account in which to receive bounces to eliminate spam and which almost all email campaigners adhere to, is thus defeating the purpose of there mission. Maybe what they do works for the small time spammer who uses a personal account to distribute spam but it defeats the purpose of eliminating non deliverables for honest mailers.

On Jun 28, 2016 3:17 PM, "Allen Coates" <[hidden email]> wrote:
Mail-server refusals (as in NOQUEUE) are generated before the email body
is received - and will also be sent to the envelope sender.

On 28/06/16 18:51, Noel Jones wrote:
> On 6/28/2016 12:12 PM, Chip wrote:
>> Meaning there are no standards for the way
>> emailers should respond to bounces?
> bounces always go to the envelope sender, regardless of any
> unrelated junk in the headers.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Jim Reid

> On 28 Jun 2016, at 20:26, Jeffs Chips <[hidden email]> wrote:
>
> I'm just saying that ALL email campaign services allow and indeed suggest users to identity a specific sole purpose email account in which to receive bounces to eliminate spam and which almost all email campaigners adhere to

The IETF process is open to all. Feel free to make use of it.

BTW, the IETF is where Internet email protocols get developed and documented. It doesn’t and can’t happen on postfix-users.

Reply | Threaded
Open this post in threaded view
|

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

Chip-2
My mistake NOT "bounces-to" rather "return-path" as in the following
snippet of campaign emails from Home Depot, Martha Stewart and Sears:

 From - Mon Jun 20 08:43:03 2016
X-Account-Key: account15
X-UIDL: UID1962-1324328699
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path:<[hidden email]>

>From - Tue Jun 21 14:39:36 2016
X-Account-Key: account15
X-UIDL: UID1969-1324328699
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path:<[hidden email]>

>From - Mon Jun 20 08:43:02 2016
X-Account-Key: account15
X-UIDL: UID1961-1324328699
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path:<[hidden email]>


So is "Return-path" supposed to be respected?  Because the company I was
speaking of insists it's appropriate to send bounces to something other
than "Return-path" usually the "From" or "Reply-to".



On 06/28/2016 03:36 PM, Jim Reid wrote:
>> On 28 Jun 2016, at 20:26, Jeffs Chips <[hidden email]> wrote:
>>
>> I'm just saying that ALL email campaign services allow and indeed suggest users to identity a specific sole purpose email account in which to receive bounces to eliminate spam and which almost all email campaigners adhere to
> The IETF process is open to all. Feel free to make use of it.
>
> BTW, the IETF is where Internet email protocols get developed and documented. It doesn’t and can’t happen on postfix-users.
>
>

Reply | Threaded
Open this post in threaded view
|

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

Daniele Nicolodi
On 6/28/16 2:01 PM, Chip wrote:
> My mistake NOT "bounces-to" rather "return-path"

This is not a subtle difference. The Return-Path header gets added (or
replaced, in the case it is already there) by the receiving MTA with the
MAIL FROM address. It is placed there only for convenience of the
receiving part.

Setting the Return-Path header on outbound messages has no effect. What
you need to change is the MAIL FROM address, as already explained a few
times in this thread.

Cheers,
Daniele

Reply | Threaded
Open this post in threaded view
|

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

Kris Deugau
In reply to this post by Chip-2
Chip wrote:
> My mistake NOT "bounces-to" rather "return-path"

Return-path is a header added by the receiving MTA (usually on final
delivery) that contains the envelope sender (MAIL FROM) used by the
sending system.

> as in the following
> snippet of campaign emails from Home Depot, Martha Stewart and Sears:

> Return-path:<[hidden email]>

Notice this one contains an extended ID number?  Their mail-sending
infrastructure almost certainly generates this pseudoaddress on a
per-mailing+recipient basis, so automated systems can quickly tell whose
email is bouncing, and which email campaign it bounced on.

> Return-path:<[hidden email]>

This doesn't use a unique envelope sender for each recipient, so they'll
have to do more complex parsing of any bounce messages to identify stale
recipients.

> So is "Return-path" supposed to be respected?  Because the company I was
> speaking of insists it's appropriate to send bounces to something other
> than "Return-path" usually the "From" or "Reply-to".

No;  as stated upthread bounces must be sent to the envelope sender
address.  Any system sending bounces to any other address is misbehaving
and may end up blacklisted (locally or in public datasources like
DNSBLs)  because of it.

All that said, if *you* are a perfectly innocent bulk-mailer who is
*receiving* bounces to the wrong place, you'll probably have to suck up
and deal with it to keep your service clean.

-kgd
Reply | Threaded
Open this post in threaded view
|

Is not honoring bounces-to violation of RFC?

Chip-2
If Return-path is added by receiving MTA, as you say, below, and that it
contains the MAIL FROM, then why do I see the following in source code
of received message in which return-path does not match From?


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path: <[hidden email]>
From: "Sears" <[hidden email]>


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <[hidden email]>
From: lucky <[hidden email]>

On 06/29/2016 10:50 AM, Kris Deugau wrote:
> Chip wrote:
>> My mistake NOT "bounces-to" rather "return-path"
> Return-path is a header added by the receiving MTA (usually on final
> delivery) that contains the envelope sender (MAIL FROM) used by the
> sending system.
>
>

Reply | Threaded
Open this post in threaded view
|

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

Emmanuel Fusté-2
Le 29/06/2016 17:02, Chip a écrit :

> If Return-path is added by receiving MTA, as you say, below, and that it
> contains the MAIL FROM, then why do I see the following in source code
> of received message in which return-path does not match From?
>
>
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 00000000
> X-Mozilla-Keys:
> Return-path: <[hidden email]>
> From: "Sears" <[hidden email]>
>
>
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 00000000
> X-Mozilla-Keys:
> Return-Path: <[hidden email]>
> From: lucky <[hidden email]>
>
MAIL FROM/envelope from and header From are two different beast.
Return-Path: is MAIL FROM/envelope from.
From: lucky <[hidden email]> in your example is header from,
witch is data and and not directly related to MAIL FROM/envelope from.


> On 06/29/2016 10:50 AM, Kris Deugau wrote:
>> Chip wrote:
>>> My mistake NOT "bounces-to" rather "return-path"
>> Return-path is a header added by the receiving MTA (usually on final
>> delivery) that contains the envelope sender (MAIL FROM) used by the
>> sending system.
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

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

Jan Ceuleers
In reply to this post by Chip-2
On 29/06/16 17:02, Chip wrote:
> If Return-path is added by receiving MTA, as you say, below, and that it
> contains the MAIL FROM, then why do I see the following in source code
> of received message in which return-path does not match From?

Could I respectfully suggest that you read up on the difference between
the envelope sender and the From header, for example here:

http://blog.tidymail.co.uk/glossary/smtp-envelope/

The two are not necessarily the same, and in fact in the examples you
showed they were not.
Reply | Threaded
Open this post in threaded view
|

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

Chip-2
I will read up on it.  Thank you for the link.

Not everyone, I think, who visits this list is an engineer.

So it would have been easier to understand if the response had been
along the lines of:

"envelope-from" instead of just FROM since there are a number of Froms
in the source code.

Someone wrote: "Return-path is a header added by the receiving MTA
(usually on final
delivery) that contains the envelope sender (MAIL FROM) used by the
sending system.


On 06/29/2016 11:22 AM, Jan Ceuleers wrote:

> On 29/06/16 17:02, Chip wrote:
>> If Return-path is added by receiving MTA, as you say, below, and that it
>> contains the MAIL FROM, then why do I see the following in source code
>> of received message in which return-path does not match From?
> Could I respectfully suggest that you read up on the difference between
> the envelope sender and the From header, for example here:
>
> http://blog.tidymail.co.uk/glossary/smtp-envelope/
>
> The two are not necessarily the same, and in fact in the examples you
> showed they were not.
>

Reply | Threaded
Open this post in threaded view
|

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

Michael J Wise

> I will read up on it.  Thank you for the link.
>
> Not everyone, I think, who visits this list is an engineer.

In that you are mistaken.

Almost everyone who subscribes to this mailing-list is an engineer.
Please re-read that line.

This mailing list is for people who need to configure or make changes to
the configuration of a Mail Transfer Agent called Postfix.
Some people here actually suggest software changes, since the author of
the system is present on the list.

Pretty much everyone here is an engineer.

RFC 821 (and its successors) is documentation of the COMMANDS (verbs, if
you will) used to move mail, of which one, MAIL FROM, is a way to express
where an NDR should go if something goes wrong.

Furthermore, at some points along the journey of a piece of mail (data, or
a NOUN if you will), it will be captured and recorded in a header, most
typically in the Return-Path value.

But it is not guaranteed to be stored in any header at any time because
it's a COMMAND to a server.

RFC 822 (and its successors) is documentation of the structure of DATA
(the NOUNS mentioned above) that represents an email message, which is
divided up into Headers and Data. One of those headers is, "From:". And
almost all of those headers are little more than comments, forgeable by
anyone with the inclination to do so, and at best advisory in nature.

So, to summarize:

The "From:" header is a comment, and may or may not reflect reality.
Typically it does, but not always.

The "Return-Path" is a recognized way to capture the value of the "MAIL
FROM:" command, and encode it into the headers, but it is best described
as a, "Virtual Header".

Some other headers inserted by arbitrary third parties are not documented
in *ANY* RFC anywhere, and almost everyone completely ignores them.

Such is the case with, "bounces-to".
It's not a standard.
Almost everything will ignore it.
People who expect it to always work should be prepared for disappointment.

Aloha mai Nai`a.
--
" So this is how Liberty dies ...          http://kapu.net/~mjwise/
" To Thunderous Applause.


Reply | Threaded
Open this post in threaded view
|

(Off-topic: who's on the list) was: Is not honoring bounces-to violation of RFC?

Miles Fidelman
On 6/29/16 2:30 PM, Michael J Wise wrote:

>> I will read up on it.  Thank you for the link.
>>
>> Not everyone, I think, who visits this list is an engineer.
> In that you are mistaken.
>
> Almost everyone who subscribes to this mailing-list is an engineer.
> Please re-read that line.
>
> This mailing list is for people who need to configure or make changes to
> the configuration of a Mail Transfer Agent called Postfix.
> Some people here actually suggest software changes, since the author of
> the system is present on the list.
>
> Pretty much everyone here is an engineer.

I could be wrong, but I expect that many of the folks here are NOT
engineers.

I happen to have an engineering background, and spend a good part of my
time doing engineering work of various sorts - but that's completely
incidental to running our mail system.  As a one-man shop, I ALSO play
sys admin, postmaster, webmaster, listmaster, janitor, chief cook &
bottle washer, ad infinitum, ad nauseum.

I expect, that many of the folks here are full-time sys admins - a role
that does not necessarily involved (or require) an engineering background.

Having said that, it seems not unreasonable for folks on this list to
have a working familiarity with the standards and software associated
with email processing.  Managing a postfix installation (or any MTA) is
not a job for amateurs.  (IMHO)

AND NOW I'M CURIOUS... What kinds of backgrounds and roles do people
here have?  Is managing a postfix installation part of your official
duties, or something that you've fallen into?

Miles Fidelman


>
> RFC 821 (and its successors) is documentation of the COMMANDS (verbs, if
> you will) used to move mail, of which one, MAIL FROM, is a way to express
> where an NDR should go if something goes wrong.
>
> Furthermore, at some points along the journey of a piece of mail (data, or
> a NOUN if you will), it will be captured and recorded in a header, most
> typically in the Return-Path value.
>
> But it is not guaranteed to be stored in any header at any time because
> it's a COMMAND to a server.
>
> RFC 822 (and its successors) is documentation of the structure of DATA
> (the NOUNS mentioned above) that represents an email message, which is
> divided up into Headers and Data. One of those headers is, "From:". And
> almost all of those headers are little more than comments, forgeable by
> anyone with the inclination to do so, and at best advisory in nature.
>
> So, to summarize:
>
> The "From:" header is a comment, and may or may not reflect reality.
> Typically it does, but not always.
>
> The "Return-Path" is a recognized way to capture the value of the "MAIL
> FROM:" command, and encode it into the headers, but it is best described
> as a, "Virtual Header".
>
> Some other headers inserted by arbitrary third parties are not documented
> in *ANY* RFC anywhere, and almost everyone completely ignores them.
>
> Such is the case with, "bounces-to".
> It's not a standard.
> Almost everything will ignore it.
> People who expect it to always work should be prepared for disappointment.
>
> Aloha mai Nai`a.

--
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

12