To be honest I don't know much about Postfix. But from this discussion, the links therein, and some Googling, it looks like Postfix isn't set up to reject mail at SMTP time, which is far and away the very best time to reject mail.

I also know that when setting up my exim server, it was quite easy to plug it into spamassassin and clamav, and simply turn away evil mail at the gate, rather than let it in, delete it, and generate a bounce that does more harm than good.

Actually, that's all quite easy to do [although note that in postfix terms, that's smtpD time [smtp refers to outgoing].

I don't want to do that, however; why should I burden my linode 360 with clamav and spamassassin; both of which can be slow and memory intensive. I let Google handle that, and I have no problem silently dropping spam mail.

The goal is to either suppress the bounce that comes from forwarding, or generate a cleaner bounce. Even with exim, if I forward a message and the forwarded recipient rejects it [maybe they reject an extension that your scanner permits?], you would have the same problem

Ah, I see, I had misunderstood your problem.

What I've found useful is to bounce back to the same gmail address. It'll bounce back and fourth a few dozen times, but eventually the attachment will be wrapped in enough attachments for gmail to no longer detect it. Then it'll be delivered.

Interesting idea, except that I probably don't want the message; I just don't want to bounce back some virus infested attachment to some poor Joe [who doesn't/won't/can't use SPF].

postfix has quite a few built-in tests that can be done at smtp transaction time (sender address verification, valid recipient, dns resolving, valid HELO, RBL checks, relaying, simple regex checking of message contents) and has the ability to delay transactions while backend processing is done (eg virus check, anti-spam).

Yesterday my linode rejected 27,000 messages at SMTP time, and only accepted 242 messages. (And that's without A/V or antispam filtering; I do that later with spamassassin and filter results into a local spambox).

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

This is a pretty good howto on implementing Postfix sanity checks. I also recommend greylisting unless you absolutely cannot tolerate a few minutes' delay in e-mail (in which case you probably shouldn't be using e-mail to begin with). We are doing absolutely no content-based filtering (e.g., SpamAssassin or ClamAV) and don't even use any DNSBLs like the howto describes, and still only a few spam messages per day get through.

FYI -- I added greylisting, and saw my spam [as identified by gmail] drop from ~100/hr -> 1 in the past 8 hours!

OK; I found a workaround; I set bounce_size_limit =5000, and now all those larger messages [containing the executables, etc] are replaced by their headers only [which is sufficient in a bounce, IMHO]

Glad it worked for you, and nice tip about bounce_size_limit - wasn't aware of that option.

I'm actually now using greylisting + SPF + reject invalid HELO's, and I only see a few unwanted messages getting into the system at all, so odds are that this will wind up being unnecessary

For some reason, though, Google thinks that my messages which are now being forwarded via procmail [to handle SPF correctly] are more likely to be spam... almost 20% of my spam folder (still, < 5 /day) are actually real messages.