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.