On 6/16/2004 9:47 AM, John Leslie sent forth electrons to convey:
Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
On Tue, 15 Jun 2004 07:58:28 -0400, "John Leslie" <john(_at_)jlc(_dot_)net>
said:
Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse.
RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert
is CA signed, then that makes sense.
I'm not sure I understand your question here. Could you clarify?
I'm saying two things.
1) Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps
neither does SMTP Auth.
True. SMTP AUTH does not tie to an IP address.
It does, however, authenticate that you're talking with an SMTP client
worthy of some level of trust (it gave an appropriate response to the
challenge you issued). It didn't seem a stretch to think that this might
sometimes prove it trustworthy enough to give a correct EHLO string.
It's a huge stretch. I must strenuously object.
E.g., here's a simple solution to the spam problem that has the same
problem. (Yeah, nominally that's not the problem we're solving; I'm just
making the point clear.)
Solution: all non-spam must include the header X-This-is-spam: false.
Only accept mail with this header.
Spammers would [include the header|use SMTP AUTH] faster than non-spammers.
They are solutions that impose requirements that spammers can meet more
readily than non-spammers.
These are, I think, examples of what Dave Crocker is calling an
'administrative attack'.
Actually that point bears amplification/restatement:
(Without the reputation services that are being contemplated,) all the
MARID proposals impose requirements that spammers can meet more readily
than non-spammers. It's been said that SPF validation currently
correlates positively with spamminess.
Having said that, it's hard to imagine the case where host name
authentication would be the only thing missing _and_ SMTP AUTH would
be in use.
So it perhaps shouldn't be part of the spec, if the purpose is just to
be a component of CSV.
I believe Dave included it for completeness of background, and it
really isn't part of our proposal.
2) Just as rDNS doesn't tie an IP to a domain for our purposes,
STARTTLS might not either - i.e. STARTTLS should be used to validate
the identity of the connection initiator, not the connection acceptor.
Agreed: if STARTTLS doesn't validate the initiator, it's useless for
host name authentication.
However, we realize there _will_ be cases where the SRV lookup doesn't
return the matching IP address, but local policy may recognize STARTTLS
as "sufficient authentication".
"_will_"? I'd say "might". I expect STARTTLS will not take off. (But
since it can authenticate the initator, if TCP traffic from an IP not
really being from that IP becomes common and IPsec doesn't, I could see
it taking off). (BTW, TLS used like this is sort of a naiive hashcash
implementation - it's expensive, as Otis points out - though he may be
referring to the cost of the CA-signed cert; I'm thinking of the CPU
cost of starting a TLS connection.)
I guess if either these two methods are mentioned here but not relevant
to CSV, that should be stated.
I can't quite agree they're "not relevant"; but I agree that a warning
label is appropriate. ;^)
Ok, I can live with that, grudgingly.
--
John Leslie <john(_at_)jlc(_dot_)net>