[Mimedefang] "<>" problem

[-]

1)  I don't see use of SpamAssassin (or any other spam detector) to review the content for possible spam.  Perhaps you should add it (or one).  Fortunately, MD will see SA if installed, so I suggest that you install it via perl's CPAN.

2)  If the spammers are seeing a greylisting result, they may believe that their message has "passed" any spam filter you do have (for which we know is none per your disclosure).  That explains why they try again (although such is a rarity among spammers, it may be possible via a botnet that uses real SMTP servers).  Spammers might assume that detected spam would not be greylisted but rejected outright (which under the current BCP is actually what should result).

3)  Without your actual filter code, it's hard to say.  However, I make the following observations which may help:

--- On Mon, 8/30/10, Jobst Schmalenbach <jobst at barrett.com.au> wrote:
> I filter all email with mime defang and I block ANYTHING
> coming with an ENVELOPE FROM from our domain, no exception.

Is that significantly different than an SPF record of "v=spf1 ptr -all" (i.e. block anything claiming to be you but not from a host in your domain)?  Perhaps you should be performing a generic SPF record check instead....
 
> How can I make sure I stop EMPTY envelope addresses but
> don't kill return receipts?

Whatever the mechanism, obviously an envelope from "<>" may not be the sole criterion.  However, it may trigger additional tests.  With SPF for example, the HELO name is tested in lieu of envelope-from; are they who they claim to be?  The problem with "<>" is that one does not have an envelope-sender to validate.

>      Message-Id: <201008301510.o7UFAWs9031632 at mail.MYDOMAIN.com.au>

This could be tricky, but a message-ID generated based on your domain coming in from the outside should only exist if:
1)  The message previously passed through your system and is being forwarded back somehow (i.e. look for a "Received:" header saying so), or
2)  The message had no message-ID field as it came in, and your system added the missing field.  This should happen only at initial submission, not transit, so if the latter, the message fails the standard and may be rejected.

>      X-Scanned-By: MIMEDefang 2.63 on 150.101.215.42

This is not the most current version.  However, upgrading isn't a solution in itself, nor will it help with this problem.

>      Aug 31 01:10:32 mail mimedefang.pl[32400]: filter relay: <64.88.187.126> <mail.soheart.com> <>

Have you actually checked to verify that "mail.soheart.com" uses IPv4 64.88.187.126 and vice-versa?  (In this case, it does, but you didn't say that you checked.)

>      Aug 31 01:10:38 mail mimedefang.pl[10335]: filter sender: 64.88.187.126 NOT DOMAIN based, <> IS NOT external domain based, continue checking ....

I'm not certain as of the rule you've implemented, but a null sender is NOT within your domain's mailbox namespace and is therefore "external."  Perhaps your coding of this is defective?