Message-Id:
<GuUKpCWT+mCHXrJh3cz8Lw(_dot_)md5(_at_)libertango(_dot_)oryx(_dot_)com>
From: Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>>
Arnt wrote:
bz writes:
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.
You're assuming that there _is_ a reverse-path for the sending party.
On the contrary, I understand that there often is no _valid_ reverse-path.
For a lot of mail here isn't, particularly the sort of mail most people
want to reject (spam and virii).
I agree.
But there is a TCP connection to the sending SMTP client. That TCP
connection is real and dependable. An SMTP server can use that TCP
connection to give an error message, and it will _not_ be giving that
error message to some unfortunate bystander.
The SMTP client may be a relay point. In which case it is REQUIRED by current
RFCs to originate a bounce message to the 'reverse-path' that may well be
forged.
The SMTP client may be a virus or virus writer. In which case the 550,
message refuse code gives information that the virus writer should not get.
The SMTP client may not be able to deal well with the error message.
That's irrelevant in theory and unimportant in practice.
Theory first: The SMTP server cannot force the SMTP client to handle the
error message well, but it never can. No SMTP server can force its
client to be well written.
Then practice: The mail you want to reject typically is spam and virii,
and the SMTP engines built into virii and spam software typically don't
forward bounces to third parties. Ergo, no big problem in practice.
It is not the virus/spam software or the forged bounces that is sometimes
sent that I am fighting against. It is the bounces that 'relays' generate
when the final SMTP server says.
550 virus found in your message.
(or something similar). And the RELAY follows the RFCs and creates a bounce
to a forged 'reverse-path'.
Big problem, in practice.
I have seen thousands of bounces in a user's inbox. Bounces from various SMTP
'relays' that were operated 'per RFC'.
--
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