@kevind To elaborate
Null senders are designed for use with non-delivery reports. An infinite loop would be created if a non-delivery report triggered a non-delivery report. So the specification says that the sender should be left null anytime that a reply might trigger a loop.
In general, it is not abused very much. Many years ago, there was a wave of attacks based on fake non-delivery reports, but they seem to have fallen out of favor a long time ago.
Note that there are two types of automated messages: Out-of-office messages are sent by the email system on behalf of the target user. The From address should be the original recipient address. I think the sender usually matches the From address, because the system knows that it should only send one out-of-office message per recipient per day.. Non-delivery notices are sent on behalf of the mail system, not the user. They have a null sender to prevent loops, and the From address is usually postmaster@targetdomain.
So how to handle fakes?
One technique is to use BATV, a technique to prove that a bounce is legitimate, by adding a secret prefix to the user portion of the sender address. It is an expired IETF draft, meaning an idea that never received official blessing, but it is used. The Wikipedia link below has a link to the original draft.
Barracuda and Office365 have made proprietary variations of this idea. Sender Rewriting Scheme (SRS) is a similar technique, and is also referenced in the Wikiepedia article. It was designed to document a forwarding operation, but it has also seen limited use as an invalid bounce detector. I have BATV on my messages because I use a Barracuda product, but it has been years since it flagged an invalid bounce.
The SPF specification says that if the sender is null, do the SPF test based on the HELO name. This is not much different from doing forward-confirmed DNS lookups, and to my mind, it is pretty useless for email security.
My solution: A null sender asserts to be an automated message on behalf of the From domain, so a more useful test is to treat the From address as the sender address, then do the SPF check on that basis. Since this is only my idea, you will not find a product that works this way. But I customized the Python PYSPF module to my liking, and I have been very happy with this solution to the authentication problem. It was an important detail for me, because I require every message to be authenticated -- unauthenticated messages go to quarantine unless they are blocked for some other reason. Code available on request.
Hope this helps.