Hello All,
This is my first posting to this particular group. I have been on the
ASRG since it inception.
I apologize if this idea has already been discussed.
My suggestion has a 'little' to do with this current thread.
Would it be a good idea to 'identify' through an added SPF TXT entry
(switch) that identifies the domain as a "non-visitor" relay point?
(e.g. port 25 is closed and all domains from this mailer have SPF
entries pointing to the relay point)
This way not all systems will be required to add extra "features" to
their mailers, only those that allow relaying through their mailers
(e.g. Hotels, Media Cafes, etc.)
This will segment the mailers and make them uniquely identifiable.
This will also require less work for administrators that do not need
this feature (if extra work ends up being required) and makes anything
you come up with easier to implement across the board.
It will also make the "non-visitor" mailers more "trustable".
Regards,
Damon Sauer
-----Original Message-----
From: Dave Crocker [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Monday, April 05, 2004 3:14 PM
To: Doug Royer
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: Benefits/costs of authorizing different identities
Doug,
DR> Are you suggesting that the EHLO/HELO be validated in addition to
DR> 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
DR> are free to create or delete accounts at any time. Which is why I
DR> favor 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
DR> 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>
*****
"The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from all computers." 113