Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23])
by calcite.rhyolite.com (8.12.8/8.12.8) with ESMTP id h24NZ8im005746
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL)
for <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> env-from
<hadmut(_at_)danisch(_dot_)de>;
Tue, 4 Mar 2003 16:35:10 -0700 (MST)
Received: from sodom (uucp(_at_)localhost)
by sklave3.rackland.de (8.12.8/8.12.8/Debian-1) with BSMTP id
h24NZ7i3024946;
Wed, 5 Mar 2003 00:35:07 +0100
Received: from sodom.home.danisch.de (localhost [127.0.0.1])
by sodom.home.danisch.de (8.12.8/8.12.8/Debian-1) with ESMTP id
h24NYIuB018298
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 5 Mar 2003 00:34:18 +0100
Received: (from hadmut(_at_)localhost)
by sodom.home.danisch.de (8.12.8/8.12.8/Debian-1) id h24NYI2q018296;
Wed, 5 Mar 2003 00:34:18 +0100
From: Hadmut Danisch <hadmut(_at_)danisch(_dot_)de>
...
Insecurity and forgeability have never ever been a design goal
of SMTP. That's a disadvantage, but not a design goal.
That is wrong if asked and answered honestly. Of course "insecurity"
and "forgeability" have not been design goals, but "receiving mail
from strangers" has been a goal.
Authentication is not magic pixie dust that can be sprinkled over a
protocol. Authenticating strangers is nonsense. A stranger is someone
you don't know, including don't know he is not a bank robber, spammer,
your long lost uncle, or all three.
Contrary to your implicit claim, sending from one IP address with a
different return IP address has always been a design goal. Sending
from one domain name with a return address in another domain has always
been an explicit design goal at least as far as the Reply-To header
is concerned. That the Sender header exists, suggests that differing
SMTP client reverse DNS domaon name and Mail_From values has been a
goal. For at least 15 years allowing such mismatches have been a
practical requirement.
Requiring that the reverse DNS domain name matches the Mail_From domain
name is as wrong aad silly as it would be to requirer that when you
send a picture postcard while on vacation you use your current hotel
as your return address. Neither requirement would reduce fraud, spam,
or anything else that is bad.
There are reasons why large ISPs would like to impose such a requirement.
The instant messaging battle between AOL and Microsoft demonstrates
why they would like it and why reasonable people oppose it.
Whether sklave3.rackland.de authenticates mail from sodom.home.danisch.de
with a Mail_from value of hadmut(_at_)danisch(_dot_)de tells no one outside
whether you are a spammer. On the other hand, if you were a spammer,
it would be trivial to finger you by contacting the operators of
213.133.101.23 or if necessary 213.133.96.29, 213.133.96.65, or
212.114.147.1.
Since both sklave3.rackland.de and calcite.rhyolite.com are running
SMTP-TLS, your mail could have been authenticated, if only my system
had a certificate. But that certificate would not tell me or my
system anything that I don't already know or would need to know about
whether your mail is spam.
If mail.rackland.de also runs SMTP-TLS and if you check its logs, you
will probably find that some spammers are also using SMTP-TLS.
That's a disadvantage, but not a design goal.
That authentication is nonsense when receiving mail from strangers
is an unavoidable disadvantage of the design goal of receiving mail
from strangers.
It has also
never been a design goal of telnet to make plaintext passwords
available to eavesdroppers.
That's irrelevant noise.
We cannot fix any security hole as long as we insist on still
fulfilling a so called "design goal" which states insecurity.
Stated honestly, that is true. Indeed, we cannot fix security
holes that are implicit in the design goals without changing
the design goals.
If your design goals imply a protocol that authenticates senders, then
use SMTP-AUTH, STMP-TLS, SMIME, PGP, or others. They are all widely
available and work fine. However, they are also useless and irrelevant
for a general mail protocol among strangers.
Keep in mind the SMTP as we know it was designed more than 20 years
ago (Jon Postels RFC 821 dates from August 1982). In 1982 and before,
there were almost no security considerations in context of internet
protocols, especially for e-mail. The security business developed in
the 90's. Plain SMTP is one of the last dinosaurs of the pre-security
era still alive.
Security didn't play any role in the design of SMTP. Even if it did,
after more than 20 years of progress in internet protocols and
security, such an age-old design goal would require some revision.
So that so called "design goal" is neither existing nor really relevant.
That is various quite wrong and entirely irrelevant.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg