Eric Shubert wrote:
It has to get a copy of the message to scan. It does not return a
successful delivery command to the sending server until the scanning
process is complete (the remote server thinks the receiving server it
still receiving the message). If it fails any of the tests, a SMTP
message is returned to the originating server and the copy of the
message that the server did receive (to scan) is discarded - this is
done before the SMTP session is closed.
The originating server usually bounces a message to the sender, but
since this is controllable it's hard to say what a given server will
do with a bounce.
Ultimately it has to get a copy of the message to scan, but leaves
the SMTP session open so that it may return an error code
(clarification: an error code is anything, even a successful code).
Once it has decided to do something with the message, it still has to
do something with the copy it got to scan.
I think it's just a matter of semantics. I see it as removing the copy
of the refused message from the queue, while you see it being
delivered to /dev/null. Doesn't really matter.
You wanted to nit pick ;)
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
