Mail Redirect Doesn't Work Right With Postfix

[rperea]

Just upgraded to version 9.0 on my test box and found that whenever you setup a redirect for a mailbox, you get a message that contains all headers and is from "POP3 Service User"

To reproduce:
1. Upgrade to 9.0 from 8.6 (Not sure if it still does this on a fresh install of 9.0)
2. Install the Postfix MTA (which should replace qmail)
3. Create an email account and set the redirect to any other email address.
4. Send a message to that email account and then check the mail that comes into the redirect address. It looks as if the mail is coming from POP3 Service User and has a bunch of headers. I believe that this is because of the blank line after the "To: undisclosed-recipients:;" line (See below)
I am running the new Postfix MTA. Here is a sample (raw source) email message that is sent to the redirect address.

Return-Path: [email protected]
Received: from imta27.westchester.pa.mail.comcast.net (LHLO
IMTA27.westchester.pa.mail.comcast.net) (76.96.62.95) by
sz0124.ev.mail.comcast.net with LMTP; Sat, 13 Dec 2008 16:12:39 +0000 (UTC)
Received: from main.test.com ([127.0.0.1])
by IMTA27.westchester.pa.mail.comcast.net with comcast
id qgCe1a0212jM21m0TgCfJR; Sat, 13 Dec 2008 16:12:39 +0000
X-Authority-Analysis: v=1.0 c=1 a=D_BVNyqSAAAA:8 a=fImTZsV6016qLbPaUgQA:9
a=3KhJ7ZPzOpY7FcAPpAEkxJMB3yIA:4 a=iYlkOlhu7C0A:10 a=tEU3DkgClm4A:10
Received: from main.test.com (unknown [127.0.0.1])
by main.test.com (Postfix) with ESMTP id AD87A2158FD5
for <[email protected]>; Sat, 13 Dec 2008 09:13:54 +0000 (UTC)
Received: by main.test.com (Postfix, from userid 110)
id A0C522158FE0; Sat, 13 Dec 2008 09:13:54 +0000 (UTC)
X-Additional-Header: CWD-/var/qmail/mailnames/test.com/test
Message-Id: <[email protected]>
Date: Sat, 13 Dec 2008 02:13:54 -0700 (MST)
From: [email protected] (POP3 service user)
To: undisclosed-recipients:;

From [email protected] Sat Dec 13 02:13:54 2008
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from main.test.com (unknown [127.0.0.1])
by main.test.com (Postfix) with ESMTP id 76CA52158FD5
for <[email protected]>; Sat, 13 Dec 2008 09:13:54 +0000 (UTC)
Received: from localhost (unknown [127.0.0.1])
by main.test.com (Postfix) with ESMTP
for <[email protected]>; Sat, 13 Dec 2008 09:13:54 +0000 (UTC)
MIME-Version: 1.0
X-Priority: Normal
X-Mailer: AtMail PHP 5.2
Message-ID: <[email protected]>
To: <[email protected]>
Reply-To: [email protected]
Content-Type: text/plain; charset="utf-8"
X-Origin: 1.2.3.4
X-Atmail-Account: [email protected]
Date: Sat, 13 Dec 2008 02:13:54 -0700
Subject: Test 5
From: [email protected]
Content-Transfer-Encoding: quoted-printable





Test 5
---- Msg sent via @Mail - http://atmail.com/

 

[rperea]

Wow, am I the only one having this problem? I did the upgrade on a second test box and I get the same results. I thought that the fix may be to add:

undisclosed_recipients_header =

to the /etc/postfix/main.cf file, But that just broke postfix so that mail couldn't be sent from any account that was also set to re-direct mail.

I think that maybe plesk is generating the virtual_domains hash incorrectly.

The line:

virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains

in the /etc/postfix/main.cf file

takes care of the forward operation (I know this because when I comment this line out, no mail gets forwarded - or delivered for that matter)

I am thinking that plesk is generating the /var/spool/postfix/plesk/virtual_domains.db file incorrectly. And the forwarded mail is not getting the To: header so postfix adds the To: undisclosed recipients:; header.

I may be way off, but this is what I have come up with. So I think that there is no workaround or quick fix for this issue unless we get a plesk hotfix.

I am going to submit a support ticket and see where it gets me.

 

[xt881m]

Just made a redirect here in Plesk9 and it's working without fault.

 

[105547111]

On my server it's working perfectly. Now spamassassin is working on the redirect address where with that **** qmail it only works on a target mailbox.

I think they did it this way so you can spam filter redirect or group addresses.

Also now at last I get the origional email direct address not the final end address as qmail did.

For me it's perfect it's fixed but agree it's different how qmail handles it.

 

[rperea]

I found that the same thing happens for mail groups as well. It looks as if anytime an email gets forwarded, this happens.

 

[rperea]

On my server it's working perfectly. Now spamassassin is working on the redirect address where with that **** qmail it only works on a target mailbox.

I think they did it this way so you can spam filter redirect or group addresses.

Also now at last I get the origional email direct address not the final end address as qmail did.

For me it's perfect it's fixed but agree it's different how qmail handles it.

Hmm.. are you running the Postfix MTA? If so then maybe something is not working right on my servers. I will look into it a bit more and post my findings.

 

[rperea]

OK, I found out what happened.
Looks like there was a modification made that I didn't know about.

It has been common practice to setup sendmail so that it adds a header for the script path so that it makes it easier to track down spammers or compromised php scripts. We used the KB article found here:
http://kb.odin.com/article_22_1711_en.html
to modify the /usr/sbin/sendmail file.

These are the commands that we used.

rm -rf /usr/sbin/sendmail;
echo -e '#!/bin/sh\n(echo X-PHP-Script-Path: $PWD ;cat) |/usr/sbin/sendmail.postfix "$@"' > /usr/sbin/sendmail-wrapper;
ln -s /usr/sbin/sendmail-wrapper /usr/sbin/sendmail;
service postfix restart;

This apparantly broke postfix when it came to redirecting emails, not sure why, because this works fine with qmail. I think that it is because postfix re-injects mail back into sendmail when forwarding email.

1. The fix was to re-link sendmail back to /etc/alternatives/mta, which is where it was linked to in the first place.

rm -rf /usr/sbin/sendmail;
ln -s /etc/alternatives/mta /usr/sbin/sendmail;

2. Modify /etc/php.ini so that mails get sent directly through sendmail-wrapper instead of sendmail.
Change:

sendmail_path = /usr/sbin/sendmail -t -i

To:

sendmail_path = /usr/sbin/sendmail-wrapper -t -i

This allows postfix to re-inject back into sendmail and bypass the sendmail-wrapper script, but still adds a script path header for php scripts.

The only thing is that some perl scripts will still use /usr/sbin/sendmail to send mail. If this is the case, then no header is added as the header is only added with sendmail-wrapper now.