Rick Macdougall wrote:
John Rudd wrote:
Diego Pomatta wrote:
That sounds more like "bounce and return" than "reject". If you
reject, the only chance you get to send an error is in the 1 line SMTP
5xx response code. If you really do mean "bounce and return" (accept
the message with SMTP 2xx code, craft a new message in response, send
it to the sender) ... that's bad, and shouldn't be used.
simscan correctly uses an SMTP REJECT (55x code during the smtp
conversation) and it is also possible to use custom reject messages with
simscan so the sender, if any, knows exactly why the message was rejected.
I have yet to see a good implementation of this in Postfix or Sendmail,
and is one of the reasons I stick with Qmail.
If you mean "custom reject message" like:
550 Appears to be extreme spam content ($score)
or
550 High Spam Probability, see http://some.url.addr/
Then that's trivial in sendmail, when using a milter. Mimedefang makes
it easy-peasy. (I do the former at home, and the latter at work)
Having to /dev/null spam and/or viruses to the end user is even worse
IMHO (as an ISP, it might be acceptable in an office env where you can
train the users to look at spam or virus folders).
IMO, there's only four acceptable actions:
1) SMTP 5xx reject
2) SMTP 4xx tempfail (ex: greylisting or actual programatic error)
3) quarantine, and some form of quarantine notification to recipient
4) deliver (with possibly adding headers, and/or subject marks, so
recipients filters can take appropriate action)
Sending an email back to the sender isn't appropriate, due to the high
likelihood that the message was a forgery. That's backscatter ... which
is bad.
Dropping, Discarding, or "/dev/null"ing a message are all showing an
amazingly inappropriate level of trust in the false positive rate of ANY
process. It's just irresponsible for a sysadmin to do that with a
user's email based on spam scores.
