This is not really a bug by most interpretations, but it does expose the holes in many email defense systems.

First, it uses a null sender (SMTP Mail From is empty).   Spammers have discovered that this is a powerful tool for confusing email filtering software that puts a lot of emphasis on the Mail From address and not much importance on the message From address.   Most legitimate messages with null sender should be non-delivery notices, but I have seen an occasional exception .

A null sender SHOULD mean "this is an automatically-generated message on behalf of the entity in the From address."    Therefore, when the sender is null, it is very appropriate to use the From address to perform an SPF check,   This also requires performing the SPF check in Declude, after the whole message has been received, rather than in SmarterMail during the SMTP session.  This blocks most all of my incoming attacks that use null sender.  (Many will note that this is NOT how the SMTP specification says you should handle a null sender.   I am saying that the specification is simply wrong.   Choose whom to believe.)

It is also very useful to perform a DMARC check on all messages.   I use the default setting of relaxed alignment.   (To reduce overhead, I don't even look for the senders DMARC policy, because I always perform the test, always ignore the configured disposition rule, and don't think the distinction between strict and relaxed alignment matters very much.)

Using these approaches, the message would have produced something other than PASS for both SPF and DMARC.   Impersonation is only ruled out when the result is PASS, so this impersonation test would have failed both tests using my scheme.  

Both SPF and DMARC will produce results other than PASS for many legitimate messages, so you need a safe way to override, based on underlying identifiers that are verified.    For SPF, the local policy rule produces SPF-equivalent PASS when the host name is verified by forward-confirmed DNS and the host domain is determined to be the source of legitimate messages for the Mail From domain.  The DMARC-equivalent rule says that a verified Mail From domain is determined to be a legitimate source of messages for a particular message From domain (even though the relationship between the two is something other than same-organization.)

Some of these null sender attacks will pass my SPF and DMARC tests, so I have an additional rule in Declude to block messages with (a) null sender, (b) no return-path header field, and (c) from domain is not in my allowed list.  The beauty of Declude is that it can enforce a rule based on multiple criteria occurring together.

To get all this done, I use Python code for SPF, DMARC, and forward-confirmed DNS tests.  All of it is based on freeware with minor customizations.   Most of my local policy is implemented using stored procedure calls to a SQL database.   Some things are still done with Declude filters because Declude does regular expressions well and SQL Server does not.   All of the code available on request.   

This is not a bug as Doug has said. It is a long known method but is becoming more common.

I actually have a filter that will HOLD a null sender incoming email with listed exceptions. 

Remember, if the war on spam were easy, it would be over by now.

In this day and age, email filtering must be a hands on eyes on ordeal, otherwise as you ask, some fufu will get through. 

To be specific, here are my two Declude filters:

*** NULLISOK filter ****  (Any match indicates a  sender is not null or null sender is plausible)

MINWEIGHTTOFAIL 1

MAXWEIGHT 1

MAILFROM    1     CONTAINS @                                # Sender is not null

ALLRECIPS       1       CONTAINS <redacted>        # BATV encoding from my gateway indicates valid bounce

TESTSFAILED     1       CONTAINS DKIMCHK-SIGNEDOK # DKIM test result on the From address is PASS

TESTSFAILED     1       CONTAINS FROMTESTPASS    # SPF test result on the From address is PASS

HEADERS        1    CONTAINS auto-submitted        # Header indicates a normal bounce messages

*** NULLSender filter ***  (When all rules match, null sender is not acceptable)

MINWEIGHTTOFAIL 3

MAXWEIGHT 3

MAILFROM    2     NOTCONTAINS @

TESTSFAILED     1       NOTCONTAINS NULLISOK