Jump to content

postfix delivered-to header exploit


cfrank

Recommended Posts

Hello everyone,

I've been using postfix as my domain mail server for 7 years, and recently I've noticed a new kind of exploit: postfix is sending bounce email to random addresses due to a Delivered-To header. I've investigated a bit and here's what happens:

Postfix receives a message for an existing local user but with a forged sender address. The message header forged by the spammer contains the following line:

Delivered-To: localuser[at]mydomain.com

along with the usual

To: "'Local User'" <localuser[at]mydomain.com>

Notice that delivery address is the same as the Delivered-To address. Next, postfix accepts the message, as being local and for an existing user, and then it immediately sees the Delivered-To header and it decides there is a mail forwarding loop going on and it bounces that message to the forged sender address.

Here's how local works, from "man local":

In order to stop mail forwarding loops early, the software adds an

optional Delivered-To: header with the final envelope recipient

address. If mail arrives for a recipient that is already listed in a

Delivered-To: header, the message is bounced.

So postfix wrongfully believes this is a mail forwarding loop and bounces to an external address, which no respectable mail agent should do. I believe this is a postfix exploit, yet I could find nothing on the web on how to stop it, except for using

soft_bounce = yes

which stops all bounces in the mail queue forever, which is not a permanent solution. Is there a way to tell postfix not to bounce messages to non-local domains, period? Or to disable the delivered-to check?

Could you please advise?

My setup never bounces messages for local or non-local users. This exploit happens with many users in the system, not just one, it's clearly not a mail forwarding problem.

I'm attaching relevant information below.

Thanks,

Cristian

postfix version: 2.6.5

headers from postcat -q :

*** ENVELOPE RECORDS deferred/C/C34291021C0 ***

message_size: 10429 249 1 0

10429

message_arrival_time: Fri Jan 8 01:34:30 2010

create_time: Fri Jan 8 01:34:30 2010

named_attribute: log_message_origin=local

named_attribute: trace_flags=0

sender:

original_recipient: KOJMedicalSupply[at]afterglowvideoart.com

recipient: KOJMedicalSupply[at]afterglowvideoart.com

*** MESSAGE CONTENTS deferred/C/C34291021C0 ***

Received: by mail.francu.com (Postfix)

id C34291021C0; Fri, 8 Jan 2010 01:34:30 +0200 (EET)

Date: Fri, 8 Jan 2010 01:34:30 +0200 (EET)

From: MAILER-DAEMON[at]francu.com (Mail Delivery System)

Subject: Undelivered Mail Returned to Sender

To: KOJMedicalSupply[at]afterglowvideoart.com

Auto-Submitted: auto-replied

MIME-Version: 1.0

Content-Type: multipart/report; report-type=delivery-status;

boundary="D0C481021BE.1262907270/mail.francu.com"

Message-Id: <20100107233430.C34291021C0[at]mail.francu.com>

This is a MIME-encapsulated message.

--D0C481021BE.1262907270/mail.francu.com

Content-Description: Notification

Content-Type: text/plain; charset=us-ascii

This is the mail system at host mail.francu.com.

I'm sorry to have to inform you that your message could not

be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can

delete your own text from the attached returned message.

The mail system

<cata[at]francu.com>: mail forwarding loop for cata[at]francu.com

--D0C481021BE.1262907270/mail.francu.com

Content-Description: Delivery report

Content-Type: message/delivery-status

Reporting-MTA: dns; mail.francu.com

X-Postfix-Queue-ID: D0C481021BE

X-Postfix-Sender: rfc822; KOJMedicalSupply[at]afterglowvideoart.com

Arrival-Date: Fri, 8 Jan 2010 01:34:27 +0200 (EET)

Final-Recipient: rfc822; cata[at]francu.com

Original-Recipient: rfc822;cata[at]francu.com

Action: failed

Status: 5.4.6

Diagnostic-Code: X-Postfix; mail forwarding loop for cata[at]francu.com

--D0C481021BE.1262907270/mail.francu.com

Content-Description: Undelivered Message

Content-Type: message/rfc822

Return-Path: <KOJMedicalSupply[at]afterglowvideoart.com>

Received: from 95-88-133-62-dynip.superkabel.de (95-88-133-62-dynip.superkabel.d

e [95.88.133.62])

by mail.francu.com (Postfix) with SMTP id D0C481021BE

for <cata[at]francu.com>; Fri, 8 Jan 2010 01:34:27 +0200 (EET)

Delivered-To: cata[at]francu.com

Received: by 95.88.133.62 with SMTP id 2sk8469083hnu;

Thu, 07 Jan 2010 18:35:28 -0500

Received: by 95.88.133.62 with SMTP id j47le64357643ciy.68.0461988292425;

Thu, 07 Jan 2010 18:35:28 -0500

Received: from Mail95.HX.GENERAL (d106-30-2-84.business2.hartmanuk.com [95.88.133.62])

by mx.jensentechnologies.com with ESMTP id 31fb01376040hzl.28.2009.12.30.08.00.55;

Thu, 07 Jan 2010 18:35:28 -0500

Received-SPF: pass (jensentechnologies.com: domain of KOJMedicalSupply[at]afterglowvideoart.com designates 95.88.133.62 as permitted sender) client-ip=95.88.133.62;

Authentication-Results: mx.jensentechnologies.com; spf=pass (jensentechnologies.com: domain of KOJMedicalSupply[at]afterglowvideoart.com designates 95.88.133.62 as permitted sender) smtp.mail=KOJMedicalSupply[at]afterglowvideoart.com

Received: from Mail95.HX.GENERAL ([fe80::d4d4:5880:270f:349e]) by

Mail95.HX.GENERAL ([fe80::d5d5:6173:795c:561j%11]) with mapi; Thu, 07 Jan 2010 18:35:28 -0500

From: "EMED Online" <KOJMedicalSupply[at]afterglowvideoart.com>

To: "'cata[at]francu.com'" <cata[at]francu.com>

Date: Thu, 07 Jan 2010 18:35:28 -0500

Subject: Changes in January

Thread-Topic: Changes in January

Thread-Index: AmtJaRHBKF85el9zUViIa7C0ocQBEN==

Message-ID: <X1CY1E5EKA01257D5IY02EE7715301878169D84287[at]Mail95.HX.GENERAL>

Accept-Language: en-US, en-CA

Content-Language: en-US

X-MS-Has-Attach:

X-MS-TNEF-Correlator:

acceptlanguage: en-US, en-CA

Content-Type: multipart/alternative;

boundary="_000_X1CY1E5EKA01257D5IY02EE7715301878169D84287shipley"

MIME-Version: 1.0

Link to comment
Share on other sites

I have found a somewhat better solution, while still not perfect.

Adding soft_bounce=yes to main.cf has the undesired effect that *all* bounces are kept in queue for a while (default 5 days) before they are ultimately delivered. This means that users who misspelled the email address will not get the immediate bounce stating that the user does not exist, or that the host name does not exist. They will get those message eventually, default after 5 days.

In order to affect only the Delivered-To header problem it's better to add one line in /etc/postfix/master.cf :

after line:

local	 unix  -	   n	   n	   -	   -	   local

add:

		-o soft_bounce=yes

Make sure you start with a white character (space or tab), that'll make it a continuation line, such that only the "local" transport gets the soft_bounce parameter, while bounces from other reasons still go through.

The messages will still bounce as spam after the 5 days, though. My solution to that was to write a scri_pt that checks the mail queue once a day for messages with the "mail forwarding loop" error, and remove them. I'm guessing there is a more elegant way to do that with filters, but it took me less time to write the scri_pt than to research into filters :-)

Link to comment
Share on other sites

  • 3 months later...

Hey cfrank!

I been having the same issue, my so well protected smtp server was somehow sending unauthorized bounce mailings for random people.. and researching the net I found your post, quite informative and that could explain exactly what was happening, thank you!

On my side I simply added a header_check on postfix in order to stop this exploit from happening, it seems to work well as i guess the local deliver does not seem to check the headers anymore once the mail is allowed to deliver. Just in case, you could point at master.cf another header_checks option without the exploit check for the local deliver.

master.cf
header_checks = pcre:/etc/postfix/header_checks

/etc/postfix/header_checks
/^Delivered-To: .*/
	  REJECT Header Exploit

B)

Link to comment
Share on other sites

I also have found out that the source of my issues were not because of the Deliver-To header exploit, but because of the option parent_domain_matches_subdomain inside main.cf which would make postfix take emails from anything[at]anything.mydomain.com without checking if the mailbox does exist. Then it would store the message for deliver and reply back with an undeliverable response to the original sender.

So I just had to define that option as empty in my config file, reload, and postfix came back to work 100% again :D

Link to comment
Share on other sites

  • 1 month later...
One thing about the header_checks rejecting the Delivered-To header is that your mailserver will reject any "foward as attachment" email. :blush:

unless you set as null, or not to run that line from header_checks at main.cf: nested_header_checks =

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...