Re: Is not honoring bounces-to violation of RFC?
On 29 Jun 2016, at 11:45, Chip wrote: I will read up on it. Thank you for the link. Not everyone, I think, who visits this list is an engineer. True, unless you accept Michael Wise's generous functional definition. I'm on the fence there, as I've held job titles calling me an engineer but my only formal engineering training was secondary to theatrical set design and construction, i.e. to make sure actors didn't die in collapses of not quite enough steel and/or wood. All of my education in "software engineering" and "systems engineering" (skills I supposedly have if you believe job titles) is from a handful of low-numbered college classes 25+ years ago and on-the-job/self training But Michael is entirely correct in that nearly everyone subscribed to this list is a de facto mail system "engineer" in that we work with the complexities of configuring and operating mail systems. So even though I don't build bridges, haven't built a stage set in decades, and don't write much ode these days, I DO "drive the trains" of multiple email systems, some of which use Postfix. So I'm an engineer, I guess. And so are you, since you seem to have run both Postfix and Exim systems at least at the "train driver" level (and frankly, railroad engineers ARE engineers to at least the same degree as sysadmins, but most of us just don't have any idea how complex trains can be...) 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. Which is accurate, if a bit ecumenical in its nomenclature... It would definitely be helpful if everyone trying to manage mail systems read RFC5598 (https://tools.ietf.org/html/rfc5598) carefully enough and often enough to adopt its formal terminology. Dave Crocker's purpose in writing that RFC was to establish precise standard jargon and a baseline understanding of how email actually works (and is intended to work) for people who should have such an understanding. If you're running a mail server, whether you accept the label "engineer" or not, you should definitely read it.
Re: Is not honoring bounces-to violation of RFC?
> 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.
Re: Is not honoring bounces-to violation of RFC?
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.
Re: Is not honoring bounces-to violation of RFC?
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.
Re: Is not honoring bounces-to violation of RFC?
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: X-Mozilla-Keys: Return-path: From: "Sears" X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-Path: From: lucky MAIL FROM/envelope from and header From are two different beast. Return-Path: is MAIL FROM/envelope from. From: lucky 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.
Re: Is not honoring bounces-to violation of RFC?
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: 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: 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
Re: Is not honoring bounces-to violation of RFC?
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
Re: Is not honoring bounces-to violation of RFC?
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: X-Mozilla-Keys: Return-path: From - Tue Jun 21 14:39:36 2016 X-Account-Key: account15 X-UIDL: UID1969-1324328699 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: From - Mon Jun 20 08:43:02 2016 X-Account-Key: account15 X-UIDL: UID1961-1324328699 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: 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 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.
Re: Is not honoring bounces-to violation of RFC?
> On 28 Jun 2016, at 20:26, Jeffs Chips 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.
Re: Is not honoring bounces-to violation of RFC?
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" 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. > > > > > > > > > >
Re: Is not honoring bounces-to violation of RFC?
> On 28 Jun 2016, at 19:28, Chip 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 representations. ... "DISPLAY_NAME" ; UTF8SMTP but no ALT-ADDRESS parameter provided, ; message will bounce if UTF8SMTP extension is not supported ; 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.
Re: Is not honoring bounces-to violation of RFC?
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. > > > >
Re: Is not honoring bounces-to violation of RFC?
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. >> >> >> >> >
Re: Is not honoring bounces-to violation of RFC?
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.
Re: Is not honoring bounces-to violation of RFC?
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.
Re: Is not honoring bounces-to violation of RFC?
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
Re: Is not honoring bounces-to violation of RFC?
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
Re: Is not honoring bounces-to violation of RFC?
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