First:  according to RFC2822 / 822  the mail header used when connecting to a remote mailserver

Mail From: This Is My Name <my.mailaddress.domain.tld>
The characters before <mailaddress>  is just a free form string with the senders name. It is normally stripped of. If looking at an incomming emial in "raw" format, the mail address string is visible as:
   Return-Path: <my.mailaddress.domain.tld>

This mail address is the one checked in Greylisting and mail header scans (white-list, black-lists)

The next issue is that during the data phase, the incomming mail often includes a "From" field. It's really up to the mail client how to display the header and data fields. According to my knowledge, most mail clients (if not all ) displays the "From" data field as is.

In short: The faked address is probably coming from the DATA filed "From" and not the HEADER Field "Mail From".
Thats why the  mail scanner and amavis failes to block.

If someone has a method of blocking when "From:" and Mail From:"  differs, let us all know!

As has been answered already in some topics, the correct place is to fight these kind of spams is in SpamAssassin.
I have no clue for the moment on how to construct such a ruleset, but if/when I do I will post a link.
The starting point might be: https://wiki.apache.org/spamassassin/

Rules should, I think, be placed in /etc/mail/spamassassin/local.cf

Free beer to the winner ;-)

Note: the problem might be "false negative reporting", but start with setting the spamscore to "+0.1" and check the result.
Test using "telnet mailserver.tld 25" using:  mail from: correct.sender@tld, rcpt to: correct.recipient@tld, data, To: correct.recipient, from: Fake.sender, and view the raw mail message (or all headers)
Regards

Hello again.
Blocking with "smtpd_helo_restrictions" will NOT solve this specific issue. Its just checks how the sending mail server identifies himself, not the actual sender individual or as the problem we have, the fake sender.

Sequence: 1) helo_hostname (= sending mail server), 2) mail_from (=Mail Envelope sender name) -> 3) From: (=Mail Header sender name)
The first two can filtered out with GreyList and various BlackLists, but the FROM: in the mail header will pass the postfix check without actions. You need  to use SpamAssassin rules to cope with  that (I guess, what I'm currently investigating)

And another note: one has to be very carefull when modifying the smtpd_helo_restrictions. The lines are evaluated in order top to down. So in Your case, you first reject "reject_non_fqdn_helo_hostname" and then "permit_sasl_authenticated". I would perhaps do it the other way around, to allow what ever hostname as long as they can log in using SASL, and then reject. But that's really up to Your environment to figure out what fits the best.
Regards, I

This is not applicable in this case.
iRedAPD doesn't get mail headers (and mail body) from Postfix, so iRedAPD doesn't know the sender address in "From:" header. which means iRedAPD cannot reject this fake email.

We put "reject_non_fqdn_helo_hostname" after "permit_sasl_authenticated" (and "permit_mynetworks") on purpose. Because many Windows OS use non-fqdn hostname, so we need to bypass them if they successfully performed smtp auth.

I think your change will cause the issue.

Also, any best practices we can adore on our email server?
Thanks.

Hello,
I think I have the same problem, we receive emails from spoofed CEO name arriving from different mailserver ( gmail too ) with different email address.

I think we can solve the problem with header_checks but I'm not skilled on this, can someone help me to write a pcre expression who says :
if the email header has first name + last name not corresponding at firstname.lastname@domain.com reject it
example

/^From:.*firstname lastname  but not if firstname.lastname@domain.com/ REJECT

regards
Stefano