These days, there are three different places where (anti-)spam filtering can happen in an email system:

1. In the user's mail client, assuming that you let them run one that has filtering rules (and most of them do). It's worth noting that there is effectively no client side filtering in webmail systems.

2. On the server once the email has been accepted at the SMTP level. This is the domain of people running procmail from their .forwards, as well as various sorts of system-wide filtering.

3. At SMTP time, so that undesired messages get SMTP level rejections. This is easily done for things like DNS blocklist checks, but can often be done with content filters as well.

Client side filtering is essentially entirely in the hands of users to both set up and maintain. You can try to distribute some standard filtering rules if you happen to have standard clients that you support, but I'm not sure how much support there is for updating them later except through manual user action (which we all know is very unlikely to happen). On the other hand, client side filtering fully empowers users to do whatever filtering they want with whatever tools they can put together. It also requires the least effort on your part, since you basically don't have to do anything; MUA authors maintain the filtering system and users maintain whatever filtering rules they want.

As someone who doesn't like to quietly drop email, it's my personal view that SMTP time rejection is the best option if you can manage it. Early SMTP rejection before DATA can significantly reduce the load on your mail system, but rejection after DATA may help less (since you have to receive the message and then run it through potentially expensive checking). Unfortunately the limitations of SMTP may make DATA-time rejection potentially chancy, since they apply to all recipients.

On the server after the mail has been accepted from the sender has been the traditional place to do filtering, at least on Unix machines. It's generally been much easier to run email through additional steps here rather than at SMTP time and there have long been robust tools for filtering, both at the individual user level and at the overall MTA level. Procmail is a classic even if it's not all that user friendly.

(As mentioned, people using webmail generally don't have a client side, so for them it is some form of server-side filtering or nothing. This filtering may run when messages are received or just when people log in to their webmail and start doing things.)

Only at SMTP time can you genuinely reject the email (although the sender may or may not pay any attention to your rejection; spammers probably won't). After that, about all you can really do is throw the message away (see this for details on why). On the other hand, if you want to let users go through their filtered out email you basically have to accept it first.