On Wed, 2004-06-16 at 11:55, Eric A. Hall wrote:
On 6/16/2004 12:39 PM, Douglas Otis wrote:
Blocking mail would be bad as static information is not comprehensive
nor would tracking all possible avenues be practical to administer.
I think that is a per-domain judgement call. I only send mail through my
mail server, so for me:
C: MAIL-FROM: <ehall(_at_)ehsco(_dot_)com>; SERVER-IP: 22.214.171.124
and all other combinations are NO.
If you are the only one using the domain, then it could be possible to
list all servers you "think" you are using. In doing so, you may
discover SMTP has been intercepted and will then need to list machines
your provider use. The policy for these machines will likely not check
for your oddly closed record as being impractical on a message basis and
often without benefit with most lists being declared open. This means
if you take the step to include these machines in your record, as must
be done in a closed list, then anyone using this information would know
how to forge your mail. : (
Other domains may want to return UNKNOWN as a default case.
Other domains would not be queried except when you reference your
provider. To keep their clients from having mail lost, their lists
would be open, so then it really does not matter where the mail comes
from, nor what the headers contain. The mail may not get a check mark,
but could, if it was also directed through these machines. A mark that
should not be trusted. : (
Anyway, as with SPF, the only really useful receiver-side response is NO,
UNKNOWN is meaningless and anybody can return a YES.
For a large system, the result will likely be Perhaps or Unknown.
There could be a system for those "off the reservation" to mail this
"domain of record" a notice to accept mail sent from their current
location, if it contained a valid signature perhaps. This could be
treated like a cache where this information would expire after so many
Receiver-side caching is part of the problem IMO. I mean, folks are shying
away from disk-based caching because they don't want to tell people that
500 mb of disk space is going to be needed, but are happy to push it to
DNS where that 500 mb of RAM is out-of-sight, out-of-mind, and thus ok.
I suspect this estimate to be high. Using a key method becomes
practical once query constraints of DNS are removed.
(out of scope for this wg)
This draft suggests use of user keys. The size could be relatively
small. Perfect for the MUA, much like browser cookies.
The next problem would be DoS. Can this be done using UDP?
DoS is a fact of life for every service.
Except that this DoS could result without hostile intent, making
spoofing even more painful that early adopters will need to endure.