Contact Form Email Header Mess
The e-mail sent to the admin/responsible from a site-wide contact form submission has duplicate header entries for "From", and "Reply-To". Due to this some e-mail clients are not able to get the correct reply-to address and we are getting a lot of email replies sent to the siteadmin (the first "Reply-To" field) instead of the person concerned (the second "Reply-To" field).
Is this a problem with the contact module? Or perhaps something being appended by PostFix during the SMTP transaction? The form headers were being sent OK before a recent upgrade to CVS 4-7 branch (contact.module,v 1.51.2.2 2007/01/26 13:56:33 killes Exp) and Postfix upgrade (2.3.8-2+b1).
A typical mail header:
To: responsibleperson@example.com
Subject: [Site] Subject
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Errors-To: siteadmin@example.com
Sender: siteadmin@example.com
Reply-To: siteadmin@example.com
From: siteadmin@example.com
From: formuser@example.com
Reply-to: formuser@example.com
X-Mailer: Drupal
Errors-to: formuser@example.com
Message-Id:
Date: Fri, 24 Aug 2007 10:50:13 -0700 (PDT)
X-Probable-Spam: no
X-Spam-Report: none
X-Scanned-By: smtp.mail.example.com
Pls help.
I hope someone will notice this post this time around.
Possible Fix (DRUPAL-4-7 CVS).
Apparently, the user_mail function in user.module (used by the site-wide contact form) was sending the "From" , "Reply-To" and "Errors-To" twice - once from the defaults and then again from the form data.
The unpleasant (not-recommended) way in which the above issue was fixed was by editing user.module:
diff user.module user.module.orig
412c412
< $defaults['Sender'] = $defaults['Return-Path'] = $default_from;
---
> $defaults['From'] = $defaults['Reply-To'] = $defaults['Sender'] = $defaults['Return-Path'] = $defaults['Errors-To'] = $default_from;
Note, despite the above line, the Return-Path will not be the same as the Sender address (atleast if you are using Postfix). The ReturnPath module needed to be installed to fix that issue.
Patch Submitted as Bug Fix
http://drupal.org/node/171118