What a recieving mail server should do is reply immediately after the DATA command with “That mail is spam and I refuse to acknowledge recieving it”. This would be fair, as the sender would know that the mail was not passed on. What it should not do is to simply say “Yep, I got this mail now, I’m good!” and then later, silently look at the contents of the mail and decide that it’s spam and delete it.
> If mail administrators bounce back an explanation for every "bad" message:
Nobody is talking (I don't thing anyone is) about sending back a bounce message, that would indeed make no sense.
A responsible email server should:
1) Reject the email during the SMTP conversation if it's going to do that. Then the sender knows it didn't go through because it got the error code. There's nothing to bounce back.
2) If it accepts the mail during SMTP conversation, then always deliver to the recipient.
2a) Some disagree, but I think it's totally fine to deliver it to the recipients spam folder if post-processing determines it might be spam. That's not wonderful, but it still got delivered and the recipient can go find it in the spam folder. Most people are used to looking there regularly anyway since many of the larger providers (coughgooglecough) have such terrible false positive rates. The important thing is to never lose email.
What's never ok is to accept the email during SMTP and then silently file it in /dev/null.
No, it's the ONLY reasonable thing to do when something like 98% of all SMTP traffic on the Internet is spam.
If mail administrators bounce back an explanation for every "bad" message:
1) Their outbound mail volume would go through the roof.
2) The host sending all the bounces would look like a spammer to _other_ automated spam-classification systems.
3) In the unlikely event that a spammer actually reads bounches, they could use the feedback to tweak their systems to avoid the spam filters.