Doug,
DR> Are you suggesting that the EHLO/HELO be validated in addition
DR> to the sender? Or as an alternate?
My guess is that we need to move Internet mail to an array of
validation mechanisms. So my simplistic response to you is "in
addition".
My more-careful answer is that we need to start somewhere that is
tractable and useful. Validating MTA.MailFrom is actually
dramatically more ambitious than validating MTA.Helo, because MailFrom
has this multi-hop chain back to the message's origination.
So I'm suggesting that we start with something that is useful and
simpler (by virtue of being much closer and dramatically more
direct.)
DR> I am not sure that would be manageable. One of my customers is an
DR> ISP that hosts over 2,000 domains per MTA. The ISP does NOT track
DR> all of the users for each of those 2,000 domains. Their customers are
DR> free to create or delete accounts at any time. Which is why I favor
DR> something like S/MIME - make the sender responsible.
If all of those domains are sent via the ISP's MTA, then only that MTA
needs to be validated. It's MTA.Helo will contain something like
mta.isp.example.com, rather than any of the 2000 domains of its users.
For that matter, consider the author-based mta registrations schemes,
like RMX or SPF. They require that each of the 2000 domains register
the ISP's MTA, as well as every other MTA any of the users of those
2000 domains might need to post through, anywhere on the Internet.
The term "scaling problem" comes to mind.
DR> What good is it to know that the HELO did in fact come from one
DR> system that can host thousands of domains?
If we want to know that message content is good, we need to validate
the content. If we want to know that an MTA is good, we need to
validate the content.
What is useful about validating that one MTA is that we will then have
a basis for trusting its traffic.
DR> How does that help
DR> control spam? I agree it would help when tracking down the source of spam.
First of all, being better able to track down the source of spam is
quite a good thing, especially compared with our current state of
affairs.
Second, depending upon the nature and strength of the MTA validation
scheme, knowing that an MTA is "well-behaved" means that it does not
send spam.
PR> More and more, I'm thinking that we should say (in answer to the
PR> original question posed about which "identity" we want to consider)
PR> that we should consider *all* of HELO/EHLO, MAIL FROM, and message
PR> header "identities". That is, whatever mechanism we come up with, it
PR> should allow a domain to publish information about any of these
PR> "identities".
This is, of course, an extremely appealing idea. My concern is that
it seems very likely to me that mechanisms for validating
chain-of-trust information must be quite different from validating
object information that can go through arbitrary intermediaries.
My own, very strong belief, is that chain of trust cannot work across
the open Internet, farther back than a peer network administration. I
can probably be convinced to trust my neighbor, but my trusting
_their_ neighbor is pretty unlikely.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>