North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Micorsoft's Sender ID Authentication......?

  • From: Douglas Otis
  • Date: Thu Jun 09 18:29:33 2005

On Thu, 2005-06-09 at 13:54 -0700, william(at) wrote:
> On Thu, 9 Jun 2005, Barry Shein wrote:

> When somebody else looks at your activity and makes "subjective" judgment 
> (mostly based on multiple reports from users) and then lets this judgment 
> about your activities be available to other users then its reputation.

This judgment of activities should be premised on knowing who is
actually accountable for the activity.  With either SPF or Sender-ID,
this mechanism is just offering server authorization.  When the
mailbox-domain appears to be supported by server authorization, without
also assuming all preceding MTAs ensure exclusive use the specific
mailbox-domain, it could be incorrect to conclude the mailbox-domain
originated the message.

Domain owners are not clearly warned by the respective drafts of this
add MTA requirement when reputation is involved.  Both drafts suggest
the mailbox-domain may subsequently accrue a reputation, when supported
by server authorization.  The SPF camp elected to drop scoped records,
which would have allowed the sender to declare which mailbox-domain has
been assured exclusivity.  Sender-ID will also use this record to
discover authorization for either the Purported Responsible Address
(PRA) or the bounce-address.  The "opt-out" solution offered by
Sender-ID will create problems at some destinations, which means both
the PRA and bounce-address require exclusivity at the MTA.  Snap goes
the Sender-ID reputation license trap.

Both schemes demand greater diligence by MTA administrators when
mailbox-domain authorization/reputation schemes are implemented, while
simultaneously leaving negligent MTA administrators unscathed.  While
this may seem like great news for the MTA administrator, and bad news
for domain owners, it risks litigation.  The mailbox-domain owner is
otherwise without recourse, when finding their domain blocked.