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

On Mon, 2005-06-06 at 14:59 -0400, Alan DeKok wrote: 
> Douglas Otis <[email protected]> wrote:
> > If SPF were used just to reject messages from unauthorized servers,
> > which is rarely the case due to path registration problems, indeed
> > there would be far less risk involved when publishing SPF records.
> 
>   So... why do "path registration" at all?  I'm still confused as to
> why it's OK for people I've never heard of to send messages using my
> mailbox address.

Excellent questions.


>   When I send messages, my outgoing MTA looks up the MX record for the
> domain of the destination mailbox, and sends the message to the
> specified MTA.  Where's the path?

The possible network addresses of where a message can be delivered for a
specific domain may only be partially resolved in an MX lookup process.
Once a valid network address has been discovered, immediate delivery
would normally be to that network address.  Once delivered, the message
may then be passed on to several other locations, before arriving at a
mailbox destination.  Often you can not know this path, nor would you
normally care.

For some organizations, the outbound network address used to send
addresses may be unknown, which is the portion of the path that SPF
attempts to register.  Organization may sub-contract services, and these
often evolve frequently.  For some organizations, the complexity of
their email infrastructure is not readily accommodated in the 100+ DNS
records allotted by SPF.


>   If we had provable senders, and signed messages, then the path
> problem would disappear.  If the transport layer, and application
> message layer are both signed and accountable, then any MTA should be
> able to transfer messages for any other MTA, and path problems become
> moot.

To some extent you would be correct.  There is still a need to protect
network resources, and this entails something other than a signature.
Protection requires authentication, or the integrity of the network
resource protection scheme would prove unsafe and unfair.  With email,
only the remote IP address or the HELO offers specific confirmation of
an actual source of a message.  Authorization can not be safely used to
infer the source of the message.


> > There is nothing provided by SPF that indicates whether 1 or 1000
> > domains use an MTA or whether any mailbox-domain was initially checked
> > for that matter.
> 
>   Is that a problem?  Publishing SPF records indicates that the domain
> owner accepts accountability for the behavior of the MTA.  Who cares if
> the MTA has another 10^6 domains, or is run by a
> <insert-prejudice-here>, or by a convict, or is in Iraq?  The domain
> owner states the MTA is accountable, so therefore it is.

While the domain owner will surely suffer the results of an MTA
administrator's lack of diligence, I would not expect any domain owner
has accepted this accountability.  I have heard time and time again,
admonishments that domain owners should ignore concerns in this regard.
SPF somehow magically protects them.  A shamefully false statement of
course.

There is even the matter of defining what being diligent entails.
Should the MTA administrator ensure exclusive use of the bounce-address
or does this also include the PRA.  There is no warning about publishing
an SPF record that includes the PRA scope.  The suggested dummy PRA
record by Sender-ID has already been declared to have limited value in
the future.  What then?

>   This objection to SPF looks a lot like an objection to *permitting*
> the domain owner to make such statements.

The publishing of these records should include a disclosure as to the
potential negative impact this record may have with the domain's
reputation.  It should describe what actions are needed by the provider,
to ensure the domain owner's protection in the all to common case of
shared MTAs.

Importantly, there should be a way to use the SPF record that clearly
indicates what is being assured by the domain owner.  The lack of
consensus regarding the version 1 record makes excluding the use PRA
impossible.  Depreciate the use of Version 1 and express the scopes
found in version 2.  This would permit a means to positively exclude the
use of the PRA.  I also see value in being able to exclude the use of
any scope, to permit this record be used for white-listing only, for
example.

-Doug