Return-Path

[msimerson]

RFC 5321, Simple Mail Transfer Protocol (updates RFC 1123, 2821) https://tools.ietf.org/html/rfc5321#section-4.4 Trace Information

When an SMTP server receives a message for delivery or further
  processing, it MUST insert trace ("time stamp" or "Received")
  information at the beginning of the message content, as discussed in
  Section 4.1.1.4.

So far, so good. Haraka does this.

A few paragraphs later:

When the delivery SMTP server makes the "final delivery" of a
  message, it inserts a return-path line at the beginning of the mail
  data.  This use of return-path is required; mail systems MUST support
  it.  The return-path line preserves the information in the <reverse-
  path> from the MAIL command.  Here, final delivery means the message
  has left the SMTP environment.  Normally, this would mean it had been
  delivered to the destination user or an associated mail drop, but in
  some cases it may be further processed and transmitted by another
  mail system.

For (mostly my) reference these terms are synonymous: Return-Path, Reverse-PATH, Envelope FROM, RFC5321.MailFrom.

In further reading, we are advised that the "destination" SMTP server MAY (but later described as lower case should) remove any existing Return-Path headers. If the SMTP server is the last SMTP hop, they are also to populate a new Return-Path header, at the top of the headers.

The text above implies that the final mail data will begin with a
return path line, followed by one or more time stamp lines.  These
lines will be followed by the rest of the mail data: first the
balance of the mail header section and then the body (RFC 5322 [4])

....

It is sometimes difficult for an SMTP server to determine whether or
not it is making final delivery since forwarding or other operations
may occur after the message is accepted for delivery.  Consequently,
any further (forwarding, gateway, or relay) systems MAY remove the
return path and rebuild the MAIL command as needed to ensure that
exactly one such line appears in a delivered message.

It doesn't appear Haraka is doing this.

[smfreegard]

Haraka isn't ever the 'final' mail destination and does not carry out final delivery with possibly exception of queue/qmail-queue plugin users, so it shouldn't ever be adding 'Return-Path' headers. I'd be surprised if qmail-queue didn't add this itself though (I don't use qmail here, so I can't comment).

On my TODO list has been to implement LMTP support so that Haraka can do speak directly to Procmail (via procmail -x via inetd/xinetd) and do deliveries directly to the UNIX mail spool; however I'm certain that it's Procmail that would add the Return-Path as it is doing the final delivery and not Haraka.

[baudehlo]

Yes, qmail-queue does add the return-path header.

Closing this issue, as unless we implemented full storage (i.e. a built-in IMAP server) we would never need to add this header.