How does one properly report delivery failure to a guerrilla spammer?
If you accept the message, you can presumably deliver it. In this day and age, anyone accepting mail for a domain without first checking the RCPT TO - even (especially?) on a backup MX - should have their head examined. In the event that the RCPT TO is valid but the message truly can't be delivered for some other reason, you should bounce the message and fix the problem. My point was that when it comes to spam, it should either be rejected inline or delivered. Unless your spam scanner has 100% accuracy, 100% of the time, there is no justification for sending anything not addressed to you to /dev/null.
"Please automatically delete anything that might be spam. They'll call me if it's important. I know I'll lose some mail, but that's okay."
If you have an agreement with a customer that specifically allows for such behaviour, great. We can get into individual cases for any concievable scenario, but that would be silly. It was pretty clear, to me at least, that we were discussing this as it would pertain to a system-wide configuration.
As for MUST bounce using return-path... perhaps you've never experienced blowback from a joe job. It can be unpleasant.
Yes, I have. And yes, it is. However, I never suggested bouncing spam, as my last message clearly stated. My position is that if you accept the message (250 OK), you have an obligation to deliver it. If you can't scan it during the SMTP transaction, do it after and mark up the headers, drop it in a junk folder - whatever - but don't delete it. St-