Strange system mail

Question

It now happened two times that I received the following mail that the system rejected a message. I originally assumed that it was an "undeliverable" message from an other server for a spam mail using us as reply-to address.
I have then looked a bit closer to the message's header and it seemed that it was sent from our own server not coming from an outside one.
Now to my questions:
Is this a mail sent by our server (running OS X Server 10.4.8) and if so, where can I find more about the access policy referred in the message ?
Is there anything I should take care or check on the server ?
This is the header:
Von: [email protected]
Betreff: BANNED (P=p003,L=1,M=multipart/mixed | P=p002,L=1/2,M=application/octet-stream,T=zip,N=Ebay.zip | P=p004,L=1/2/1,T=exe,T=exe-ms,N=Ebay.jpg.exe) IN MAIL FROM YOU
Datum: 17. März 2007 00:59:16 MEZ
An: [email protected]
Return-Path: <[email protected]>
Received: from murder ([unix socket]) by domain.tld (Cyrus v2.2.12-OS X 10.4.8) with LMTPA; Sat, 17 Mar 2007 00:59:16 +0100
Received: from localhost (localhost [127.0.0.1]) by domain.tld (Postfix) with ESMTP id 871F810440C6 for <[email protected]>; Sat, 17 Mar 2007 00:59:16 +0100 (CET)
X-Sieve: CMU Sieve 2.2
Mime-Version: 1.0
In-Reply-To: <001501c76827$1e04e900$0100007f@pamela>
Message-Id: <VS15259-10@localhost>
Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1174089556-15259-7"
And here is the message content:
BANNED CONTENTS ALERT
Our content checker found
banned name: P=p003,L=1,M=multipart/mixed | P=p002,L=1/2,M=application/octet-stream,T=zip,N=Ebay.zip | P=p004,L=1/2/1,T=exe,T=exe-ms,N=Ebay.jpg.exe
in email presumably from you (<[email protected]>),
to the following recipient:
-> [email protected]
Our internal reference code for your message is 15259-10.
Delivery of the email was stopped!
The message has been blocked because it contains a component
(as a MIME part or nested within) with declared name
or MIME type or contents type violating our access policy.
To transfer contents that may be considered risky or unwanted
by site policies, or simply too large for mailing, please consider
publishing your content on the web, and only sending an URL of the
document to the recipient.
Depending on the recipient and sender site policies, with a little
effort it might still be possible to send any contents (including
viruses) using one of the following methods:
- encrypted using pgp, gpg or other encryption methods;
- wrapped in a password-protected or scrambled container or archive
(e.g.: zip -e, arj -g, arc g, rar -p, or other methods)
Note that if the contents is not intended to be secret, the
encryption key or password may be included in the same message
for recipient's convenience.
We are sorry for inconvenience if the contents was not malicious.
The purpose of these restrictions is to cut the most common propagation
methods used by viruses and other malware. These often exploit automatic
mechanisms and security holes in certain mail readers (Microsoft mail
readers and browsers are a common and easy target). By requiring an
explicit and decisive action from the recipient to decode mail,
the dangers of automatic malware propagation is largely reduced.
For your reference, here are headers from your email:
------------------------- BEGIN HEADERS -----------------------------
Return-Path: <[email protected]>
Received: from web.de (unknown [69.31.159.25])
by domain.tld (Postfix) with ESMTP id BC70810440C0
for <[email protected]>; Sat, 17 Mar 2007 00:59:13 +0100 (CET)
Date: Fri, 16 Mar 2007 17:59:22 +0300
From: "Ebay.de" <[email protected]>
To: <[email protected]>
Subject: EBay-Hinweis zu geanderter E-Mail-Adresse
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
MIME-Version: 1.0
Message-ID: <001501c76827$1e04e900$0100007f@pamela>
Content-Type: multipart/mixed; boundary="----=NextPart_000_001201C767F4.9F599D80"
X-Priority: 3
-------------------------- END HEADERS ------------------------------
Reporting-MTA: dns; localhost
Received-From-MTA: smtp; domain.tld ([127.0.0.1])
Arrival-Date: Sat, 17 Mar 2007 00:59:16 +0100 (CET)
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 550 5.7.1 Message content rejected, id=15259-10 - BANNED: P=p003,L=1,M=multipart/mixed | P=p002,L=1/2,M=application/octet-stream,T=zip,N=Ebay.zip | P=...
Last-Attempt-Date: Sat, 17 Mar 2007 00:59:16 +0100 (CET)
Received: from web.de (unknown [69.31.159.25])
by domain.tld (Postfix) with ESMTP id BC70810440C0
for <[email protected]>; Sat, 17 Mar 2007 00:59:13 +0100 (CET)
Date: Fri, 16 Mar 2007 17:59:22 +0300
From: "Ebay.de" <[email protected]>
To: <[email protected]>
Subject: EBay-Hinweis zu geanderter E-Mail-Adresse
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
MIME-Version: 1.0
Message-ID: <001501c76827$1e04e900$0100007f@pamela>
Content-Type: multipart/mixed; boundary="----=NextPart_000_001201C767F4.9F599D80"
X-Priority: 3
(Since I'm a bit paranoid, I replaced our domain name in header and body by domain.tld, so don't wonder

Answer 1

In short, I was running a website (no mail services at the time) that was heavily dependent on PHP for dynamic content, I was told that we were on the latest security patchlevel for all the software on the box.
A hacker took advantage of a security hole in the old version of PHP we were running (which the hosting company told me had been patched) to install a suite of spam generators and backdoors.
I found out about the hack when my hosting company shut down my server for "excessive bandwidth" which I didn't understand since our site was running very slowly. I had to go to the hosting company to log in to the box, and found so much excess crap running I couldn't believe what I was seeing. My website was being used to send out mass amounts of spam, as well as blast IP packets at an IP that I learned was a bank in Hong Kong. Along with all the other stuff, a timer process was running (with an artificially small pid - don't know how they did that....) that would create a root-level user whenever it wanted to.
I had to take my SQL dumps and my initial-state backup (thank god I did that before taking the site live) and reconstruct the server after deleting everything and reloading the latest versions and patches of everything.
That experience has made me very jumpy when it comes to server security.
Bottom line is, I monitor the websites of all the S/W I depend on for security announcements, and I'm constantly on the alert for issues which would apply to me.
Sorry if I frightened anyone, but the email header that Tobias posted looked eerily similar to what my server was sending out when it was under the evil influence.
-Gregg