Re: Philosophical discussions (was Re: draft-schlitt-spf-classic-01.txt )

On Tue, 2005-06-07 at 19:24 -0400, Alan DeKok wrote:
> Douglas Otis <[email protected]> wrote:
> > 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.
> 
>   But if I deliver a message to the MX that is authoritative for the
> domain of the mailbox, the message is *delivered*.  It's *done*.
> You're assuming that *my* message gets forwarded *from* the domain I
> sent it to, and that it's still marked as *my* message.
>
>   If it does, I don't see why it's labeled as "my" message.  The
> historical approach to label it that way is nice historically, but
> there appear to be some kind of abuse issues associated with it...

Assume you sent a message to a simple exploding list for example.  While
you could conclude that once the list server accepted your message, it
now becomes the list server's message.  From a reputation standpoint,
this is not desirable from the perspective of the list operator, who
would like any abuse to directly impact those they see as accountable.

The abuse that concerns you has to do with how the accountable entity is
determined.  If the accountable entity is determined by some
mailbox-domain having authorized a sending server, then indeed this can
lead to failure or abuse, especially when many domains authorize the
same sending servers.  On the other hand, if the accountable entity is
determined by validating a signature using a key published by the
sending domain, then any opportunity for this to be abused is
dramatically reduced.

Assume you send a message to a forwarding account that acts as an alias
for the recipient.  You consider the message being forwarded, by having
the recipient altered on the envelope, to be technically a modified
version of your message.  Nevertheless, the content of your message
remains unaltered.  Where a delivery failure notice must be sent also
remains unchanged to provide the eventual recipient this essential
information.

It makes no sense to alter the information that normally gets forwarded
to satisfy a flawed scheme that infers the source of a message through
server authorization.  This is where abuse may occur, as
server-authorization being considered equivalent to
sender-authentication is a scheme that unfairly makes assumptions of
origin.

I see no problem having high thresholds on the HELO or IP address of the
sending server to form a basis for network protection.  I see no problem
allowing forwarding or list servers (leaving mail unaltered), and
relying upon signature validation to determine accountable entities as a
basis for recipient protection.  However, there is no reasonable method
to base accountability of a message upon the server having been
authorized.


> > 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.
> 
>   Sure.  But if they choose to accept that accountability, isn't that
> their choice?

In the many presentations I have attended, I have yet to hear any
warnings that by publishing an SPF record, the domain owner's reputation
may become damaged beyond their control, regardless of the type of list
published.  I have not heard anything beyond a warning there may be some
reputation risk related to publishing an "open-ended" list.  Seldom is
this explained to mean either risk some messages being lost when
forwarded in some fashion, or risk readily obtaining a bad reputation.
Of course, even a "close-ended" list can not offer substantial
protection from forgery when the MTA is shared.


> > The suggested dummy PRA record by Sender-ID has already been
> > declared to have limited value in the future.  What then?
> 
>   They can use a proposal that doesn't have problems.

Which proposal is that?  It is not draft-schlitt-spf-classic-01, or
draft-lyon-senderid-core-01.  These two drafts are in serious conflict,
and the Sender-ID draft claims that server authorization is equivalent
to sender authentication, whether for the bounce-address or the PRA.  Do
you really think it is safe to ignore the intentions of Microsoft?


> > 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.
> 
>   That's a matter for the documentation of the proposal, not for it's
> implementation.

I hope they consider the outcome of having withheld this information.
Class-actions love deep pockets.  : )


> > Importantly, there should be a way to use the SPF record that clearly
> > indicates what is being assured by the domain owner.
> 
>   Of course.  Any similar system should have similar assurances.

Even by obtaining the record's scope, SPF/Sender-ID assumes email
providers are perfect at assuring exclusive use of a mailbox-domain
within this scope.  Have you seen any indemnification making this claim?
This scheme is filled with assumptions and false assurances.  If you do
not run your own MTA and can assure exclusive access, SPF/Sender-ID is
an extremely risky choice.  Unless you are willing to have some messages
go missing, SPF/Sender-ID is an extremely risky choice.

The safer choice is DomainKeys upgraded to DKIM. : )

-Doug