> 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.
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.