About the Return-Path header

The most common error senders make is adding a Return-Path header to their mail. Even some well known mail software does this. Probably written by programmers who copy from others rather than reading RFCs (the internet standards that specify SMTP and MIME).

Update: As of PHPMailer version 5.2.8 the Return-Path header is no longer set in created messages.

1. RFC5321 does not forbid to set Return-Path in the origin. It only says what SMTP server MUST DO:
   Section 4.4.

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

   and later

   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.

   Later RFC even talks about the case where Return-Path is added by the originating client, but again it doesn't forbid it.
   Section 4.4.

   A message-originating SMTP system SHOULD NOT send a message that
   already contains a Return-path header field. SMTP servers performing
   a relay function MUST NOT inspect the message data, and especially
   not to the extent needed to determine if Return-path header fields
   are present. SMTP servers making final delivery MAY remove Return-
   path header fields before adding their own.

   Note "SHOULD NOT" here. As explained in RFC2119:

   SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

2. RFC5321 states that MAIL FROM: header is always the sender mailbox and nothing else.
   Section 3.3.

   The <reverse-path> portion of the first or
   only argument contains the source mailbox (between "<" and ">"
   brackets), which can be used to report errors (see Section 4.2 for a
   discussion of error reporting).

   Section 4.1.1.2.

   The reverse-path consists of the sender mailbox. Historically, that
   mailbox might optionally have been preceded by a list of hosts, but
   that behavior is now deprecated (see Appendix C). In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and non-delivery notifications), the
   reverse-path may be null (see Section 3.6).

   Note that here it states that the same sender mailbox can be used for error reporting, but this doesn't mean that, in case of a mailing list or other specialized bounce mailbox present, error reporting must always go to the MAIL FROM: address.
3. RFC5321 clearly states that in some cases Return-Path could be completely different than the sender address and a system should not assume otherwise.
   Section 4.4.

   It is possible for the mailbox in the return path to be different
   from the actual sender's mailbox, for example, if error responses are
   to be delivered to a special error handling mailbox rather than to
   the message sender. When mailing lists are involved, this
   arrangement is common and useful as a means of directing errors to
   the list maintainer rather than the message originator.
   
   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]).

   and Section 7.2.

   There is no inherent relationship between either "reverse" (from
   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
   transaction ("envelope") and the addresses in the header section.
   Receiving systems SHOULD NOT attempt to deduce such relationships and
   use them to alter the header section of the message for delivery.

4. PHPMailer removed automatic setting of Return-Path header in 5.2.8 and in most cases, where a client just needs to send simple email, this is correct, but this doesn't mean that custom Return-Path header cannot be added. For example, if I would want to implement a mailing list software fully in PHP language by using PHPMailer I would need to set different MAIL FROM: and Return-Path headers otherwise it won't work. The same goes for LimeSurvey. As it has bounce processing capabilities it is not really a client anymore. It is an email processing server software and should modify Return-Path accordingly, using addCustomHeader() as an example.

ViliusS wrote: I don't think that your response is appropriate and up to open source standards and spirit. Your messages doesn't answer anything or add any value to the community. If that's not the place to start the discussion regarding LimeSurvey functionality and in a process to try to make it better, fine by me.

If you don't care, I won't spend any more of my time here either.

Our great community is an experienced, reliable and versatile helper. Any difficulties you may come across have likely already been detected by someone else. Most of the times that someone has also found a solution to the problem. Our community is the ideal place to ask questions and get help with any issues regarding the usage of LimeSurvey. A part of our community deals with documentation and translation. If you want to help out, this is your place to go.