ietf-mxcomp
[Top] [All Lists]

Re: draft-schlitt-spf-classic-01.txt

2005-06-03 14:28:19

Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
Going down the list of identifies available that could isolate security
and abuse issues to the accountable administrator, it would be:
  - IP Address
  - Authenticated HELO Name
  - Validated Signatures

You will notice that the mailbox-domain is not in this list.

  s/this/your/.  Not everyone agrees.

  I have vanity domains where I'm the only person with mailboxes at
the domain.  I *am* the accountable administrator for that domain, and
I would like to be able to state so.  I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.

  Some proposals allow me to do that.  The original purpose behind RMX
was exactly that: Hadmut had a vanity domain, and couldn't stop people
from forging messages using that name.  Hadmut was also very clear
that not everyone would want to use RMX, but the people who would use
it could protect themselves.

  The response then, as now, is that there is absolute opposition to
such proposals.  The requirement that we permit ".forward" style MTA's
to use third-party domain names is a requirement that people like
Hadmut and myself cannot prevent others from forging spam using our
names.

  This mailbox-domain identity is passed from MTA to MTA, and is
unrelated to an accountable administrator.

  Ah, yes.  If we assume the current behavior is desired, then the
conclusions are foregone.

  If, on the other had, we have the temerity to question the existing
assumptions, then the conclusions are questionable, too.

SPF or Sender-ID also makes a false assumption that the MTA is not
shared, or that the MTA administrator ensures user/mailbox-domain
relationships are protected.

  SPF and related proposals allow the DNS administrator to claim that
the MTA satisfies certain criteria.  But this benefit is being turned
around, and claimed to be an accidental, and negative side-effect.

I have yet to hear anyone caution domain-owners they should first become
indemnified in their provider's SLA, and be assured only their messages
are permitted to use their domain in the bounce-address

  For me, it isn't so much about permission as audit trail.  If I
can't prove a particular message using a mailbox address is actually
associated with that address, then I have no idea if the message is
forged or not.  Signatures don't help, as anyone can create a
certificate or key for any identity they want.

  What matters is the "web of trust", or the relationship.  Signatures
*can* help if the certificate for "user(_at_)example(_dot_)com" is signed by the
key for "example.com", and the key for "example.com" is signed by a
known CA.  In that case, the signatures are a means to an end, not a
solution in themselves.  They make the relationship management easy
and reliable, nothing more.

  Alan DeKok.