On Tue, 20 Aug 2002 15:27:18 PDT, william(_at_)elan(_dot_)net said:
It it seriously not capable of handling what is needed, particularly any
kind of verification, callback, exchange of certificates, etc, etc.
Those are *specific* extensions. The general framework of EHLO has been
shown to work fine.
ETRN can be extended. Unfortunetly I do not see mail server operators
adobpting new extensions unless they have more reason then just this.
The whole idea is to do it all together and make serious case for upgrade.
Given the number of things you'd have to upgrade, you had better show some
*really serioys* wins compared to what SMTP+EHLO can do before you're going
to see much chance of deploying.
First of all I do not disagree that its out of scope. Second I'v actually
done technical work on this issue and I have SMTP working over SSL tunnel
as do many other but its not as simple as this and we need standards on
how SMTP certificates would be issued, etc. The problem is that there is
no standard on this and no wide use and only few MTAs have any kind of
support for it. And if you notice I'm actually big advocate of using
certificate for mail transmission & server verification and I know all
about this - I do not see it being used in many places (and its a good
way to stop SPAM BTW) until more work has been done on it.
Actually, given that Sendmail 8.11 supports it, a *LOT* of MTAs have
support for it. What you're seeing is the fact that few sites *enable*
the support.
I don't see that we need a standard for "how SMTP certificates are issued".
We already understand *very* well how to issue host certificates - if we
didn't, the https:// protocol would be quite DOA.
I'm not at all convinced that certificates for "mail transmission & server
verification" are as big a win as you might think. What you probably *want*
here is more end-to-end verification. Which do you care more about - that
the machine that submitted the mail to loki.ietf.org was authenticated,
or that it can be shown that I was the author of the mail? Consider - the mail
I'm replying to had 9 Received: headers - only 2 of which were done by
machines that I fully trust, and another 2 by machines run by people I
can smack upside the head if they screw up. I suspect that at 4-of-9,
I have more control of the path than 99.999998% of the net's users.
5. Callback verification
This group will also work in conjunction with group#2 on how callback
mechanisms can be used to verify authenticity of mail servers. Work would
also
be done on callback verification as proposed at draft-nunn-ssmtp-00.txt
draft.
And this needs a new working group why, rather than doing it in the
IETF-SMTP
group?
Since you mention it again, I do not see IETF SMTP working group in the
list of current working groups. And there was no organized effort to work
on SMTP for quite some time except for S/MIME. There are some groups
workin on unified messaging but this is not the same.
Odd, there was a lot of traffic on the list for discussing CONNEG.
You might also ask yourself what callback buys you security-wise on the
Internet - is there a realistic case where callback buys you anything?
Remember if they can hijack the 3-packet handshake for the *original*
connection, they can do it to the callback (and with even MORE opportunities
for fun and games - if I can make you do a callback I know when to drop
in my DNS cache poisoning or whatever).
Callback *partially* closed a number of problems with dialup modem access
(note however that most devices that did callback on the same line as the
inbound request were *painfully* easy to exploit, and even callback on a
second line still had race conditions). I'm not convinced that said holes
are the same on the IP network as they were on the POTS network.
SMTP AUTH sends passwords in clear text for starters.
It does? CRAM-MD5 and DIGEST-MD5 are cleartext? See RFC2554 and RFC2222.
Delivery confirmation will only be solved issue when everyone supports it.
The point is that the *standard* is there, and most MTAs *do* support it to
some extent, but it's usually disabled for very good reasons - people seem
to have an innate need for plausible deniability. We've *all* read our
e-mail at 4:50PM on a Friday and found a piece of mail we wish we hadn't
seen until 9:05AM Monday. The last thing we want at that point is a
smoking-gun proof that we DID see it at 4:50 Friday.
Address verification in its current form is unsecure that is why everyone
disables it. But it is usefull feature to have and we need to look into this.
Again, the standard is there. The standard is even flexible enough that
you can get away with answering VRFY/EXPN fully and accurately for queries
from some hosts (perhaps those in your administrative domain), issuing
partial answers for others (perhaps VRFY but not EXPN), and saying "Unsupported"
to other sites.
However, that's the proper realm of the programmer doing the code, and then
for the salescreature to brag up as a selling point. The IETF has done its
part there, it's not our fault MTA developers don't provide better controls
on VRFY/EXPN.
Remember - some of us have been doing this for a LONG time, and there's a
lot of dragons with subtle camouflage but pointy sharp teeth. There's a
very good chance that if you're asking yourself "why hasn't anybody done
this before?", that it HAS been thought of before, and that it's either
a lot harder to do correctly than it looks, or it's not addressing the
problem, or both. Even the experts can get it wrong - this time last week,
I had 3 or 4 very recognizable names telling me exactly why an idea of mine
wasn't as generally applicable as I thought (thanks guys - turns out if
I had deployed it, I'd have broken my boss's email, for exactly the reasons
you cited it as a bad idea ;)
Step 1: Ask if it's doable now with COTS software. If it is, it's a
problem for your purchasing department, not the IETF.
Step 2: Ask if it's supported by the RFCs but not shipping. If it is,
it's a problem for your vendor to fix, not the IETF.
Step 3: Ask if it's (a) reasonable and (b) addresses the problem. If it's
not both, you need to reformulate the problem and/or solution.
Step 4: Start thinking if an I-D is a good idea - *NOW* it's an IETF problem.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
pgpU94gTtxioi.pgp
Description: PGP signature