Message-Id:
<oD6UfAkRcBbkEi/ABDQRhg(_dot_)md5(_at_)prosecco(_dot_)oryx(_dot_)com>
From: Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>
In-Reply-To: <7382FCA44E27D411BD4A00508BD68F950AE30F04
@pigeon.tumbleweed.com>
Daryl Odnert writes:
But why should the SMTP protocol preclude server implementations from
performing local policy analysis after the message has been accepted
from the client?
Because if you want to give an error message to the party who actually
sent you the email, you have to talk to that SMTP client. (Even that's
not a sufficient condition, merely a necessary one.)
That is not even necessary.
If you want to give an error message to the party who actually sent you the
e-mail you need to know the real 'reverse path'. This may have nothing to
do with the SMTP client the message was receive from.
The validity of the return path can often only be determined AFTER the
message has been accepted. Once the message is accepted from the client,
analysis can show that the message did NOT come from where it claims to
come from.
In such a case, it is WRONG to 'bounce' to that address. That address had
nothing to do with sending the message. That address should NOT be
'spammed' with 'bounces' of messages that it did not send. Doing so
victimizes the owner of the forged address.
There are half a dozen or so places in RFC2821 that need to be changed so
as to 'legalize' the practice that has become vital to the continued
existance of e-mail. The practice of 'dumping' know viruses should be
encouraged. The practice of 'bouncing' those messages should be
discouraged.
--
bz
please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
infinite set.
bz+ietf(_at_)chem(_dot_)lsu(_dot_)edu