Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too.

From: "Jim Lyon" <[email-masked]>
Date: Fri, 27 Aug 2004 14:52:56 -0700

On Thursday, August 26, 2004 at 5:07 PM, Douglas Otis wrote:

> The Identity being authorized is the PRA Mailbox Domain by way of
> reference to a Mail Channel prescription of IP addresses.

No, please try reading it again. The identity being authorized is the
sending MTA's IP address.  The action being authorized is to send a
message on behalf of the PRA.  The organization doing the authorization
is the domain of the PRA.

> (... yet another advertisement for CSV ...)
Ignored as not relevant.

-- Jim Lyon

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Aug 2004 19:15:31 -0400

> is the domain of the PRA.

   Jim is exactly right.

   The SPF2 record specifically authorizes a list of IPs to send mail
on behalf of the domain part of the PRA.

   CSV, on the other hand, authorizes a specific host-name to send mail
as directed by the domain which that host-name belongs.

   Actually, these two functions are remarkably similar: both are
optimized to validate the last hop before the recipient domain; neither
validates a field ordinarily seen by the recipient of the email.
Why are we arguing which way is better?

   Doug and I both came into this WG concerned about reputation services.
We both looked at the SPF record format and despaired of designing a
system of reputation services which could say whether a SPF domain is
worth trusting. We backed away from that and looked at a hop-by-hop
reputation service. This we believed was practical. Our design can be
found in the CSV documents.

   I've been mostly quiet during the SenderID discussions, feeling I
don't have much to add. Doug has put forth ideas as they occur to him;
sometimes passing them by me first, sometimes not. I wish people were
more receptive to his ideas; but that's not the purpose of this email.

   As the discussion has progressed, I've learned how similar to CSV
SenderID actually is. I now believe a system of reputation services
could be designed for it. But I'm not sure anyone would like it.

   We start by agreeing that the exact domain-part of the PRA is the
unit to be accredited; and presume some (unspecified) DNS lookup for
reputation information.

   We then evaluate the list of IPs authorized by the SPF2 record,
and run them against known IP blacklists; accumulating a score based
on weighting the reputation of those blacklists for spam identified,
false negatives, and false positives.

   Now the part you probably won't like: we must assign low weighting
to blacklists with high false negatives, while we can't assign low
weighting to blacklists with moderate false positives. Worst of all,
we can't assign any positive score to IP addresses not on any blacklist.

   Thus, in essence, we'll be producing ratings _highly_ correlated
with the number of IP addresses authorized by the SPF2 record, and
even for domains which only authorize a very few IP addresses, we'll
have no practical way (except manual processing of requests) to
correct outdated blacklist listings.

   We can, of course, include the suggested-service features of the
CSV proposal, but the reputations of suggested services would have
to be pretty-darn-good to outweigh the algorithm listed above.

   Can anybody design a better system of reputation services for
SenderID?

--
John Leslie <[email-masked]>

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Aug 2004 16:43:36 -0700

I'm hesitant to discuss this on the list right now, during last call, but briefly:

You seem to be describing the problems associated with arriving at a reputation for the domain-part of a PRA, given that you have a reputation database that's keyed by MTA address.  But wouldn't it be possible to create a reputation database based on the domain-part of the PRA itself?

I don't think this is by any means a trivial task, though.

-Jim

---

From: "Mark C. Langston" <[email-masked]>
Date: Fri, 27 Aug 2004 17:08:42 -0700

On Fri, Aug 27, 2004 at 04:43:36PM -0700, Jim Fenton wrote:
> You seem to be describing the problems associated with arriving at a
> reputation for the domain-part of a PRA, given that you have a
> reputation database that's keyed by MTA address.  But wouldn't it be
> possible to create a reputation database based on the domain-part of
> the PRA itself?
> 

The GOSSiP Project (http://sufficiently-advanced.net/ ) could handle
this, I believe.  Right now, it's using as an identity the RHS from
RFC2821 MAIL FROM: and the sender's IP address as reported by the MTA.
However, this same approach could be used for any arbitrary identity
scheme.

All that would be necessary would be agreeing to the structure of an
ID to use for submission of PRA data to a GOSSiP node.  In fact, 
the current GOSSiP id approach and a method of tracking PRA reputation
within GOSSiP could be used simultaneously.

We're about a week or two away from a limited test release, and are
aiming for an initial public release sometime in November.

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
[email-masked]   http://sufficiently-advanced.net    [email-masked]
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org       E-mail Reputation       http://www.seti.org

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 27 Aug 2004 18:03:47 -0700 (PDT)

The significant problem I see with depending upon the authorized PRA
Mailbox Domain for assessing complaints is that this identity has not been
authenticated.  What the PRA Mailbox Domain provides is whatever can be
deduced about the message emerging from an otherwise anonymous MTA where
only the IP address is certain.  If one were to expect that when a PRA
Mailbox Domain is using an MTA with a decidedly blacklisted IP address,
then by extension all the published MTA addresses for this PRA Mailbox
Domain should be blacklisted.  That would be a fatal conclusion.

It would be difficult to conclude anything about the message content which
formed the premise for the PRA Mailbox Domain while the trustworthiness of
the MTA remains unknown.  Is this domain using an "open-ended" list?  Is
this a shared MTA?  Is the recipient's mail relay secure.  Has all the MTA
servers performed the required PRA Mailbox Domain to Mail Channel
prescription checks?  It gets ugly.  There will be an endless array of
fingers pointing in every direction, but the domain being harmed by the
reputation assertion will be pointing their finger at the reputation
service.

There is far too much uncertainty in this for any assertions to be applied
with respect to a Mailbox Domain against a Mail Channel prescription other
than to say the message is authorized or not.  It would even be dangerous
to treat "authorized" as having any great significance.  It is vital for a
reputation service that the identity used be authenticated and not just
authorized.  In other words, is it reasonable to assume this entity is the
bad actor?  Some may take the attitude they should find a better mail
provider should they get listed.  It may not have been their mail provider
at fault however.  Mail gets relayed through administrative domains where,
at any point, there may be a lapse in control over access to the mail
channel.

This is why it is vital that reputation services be built upon the CSV
results, rather than depending upon the Sender-ID identity to serve this
function.  If the expected outcome of all the finger pointing results in
the routine insertion of a Resent-From header, then there is virtually no
difference between the identities being used between CSV and Sender-ID at
that point.  There is a significant difference in the strength of the
authentication of these identities however.  CSV isolates the
authentication to a single administrative domain.  Sender-ID may isolate
the authentication to hundreds of administrative domains.  This is a huge
difference when one is attempting to block the bad actor, but where the
bad actor may be masquerading as one of any of these administrative
domains.  Worse yet, if there is an "open-ended" list used, then the bad
actor could be anyone regardless of the level of certainty obtained from
Sender-ID due to the problem of "validation promotion".

-Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 28 Aug 2004 18:32:19 -0700 (PDT)

On Fri, 27 Aug 2004 14:52:56 -0700 Jim Lyon wrote:
> On Thu, 26 Aug,2004 at 5:07 PM, Douglas Otis wrote:
>> On Thu, 2004-08-26 at 15:56, Jim Lyon wrote:
>>> On Thursday, August 26, 2004 at 1:35 PM, Doug Otis wrote about the
>>> authentication and authorization aspects of SenderID, compared to
>>> schemes involving EHLO.
>>>
>>> After much thinking, I realized that our disagreements have to do with
>>> confusions about how the two schemes treat identity, authentication and
>>> authorization.
>>>
>>> Sender-ID:
>>>
>>> Identity:  The identity of a sending MTA is its IP address.
>>>
>>> Authentication:  There is no authentication other than that implicit in
>>> the TCP/IP stack.  Because in practice you can't perform an SMTP
>>> transaction without being able to receive packets destined to the IP
>>> address, this works well. (Yes, I know about TCP/IP spoofing attacks,
>>> but they're impractical for sending bulk e-mail.)
>>>
>>> Authorization:  The SenderID test determines whether the sending MTA is
>>> authorized to send mail that claims to come from a particular domain.
>>> This authorization can only be bestowed by the domain that the mail
>>> claims to come from.
>>
>> reference to a Mail Channel prescription of IP addresses.  This PRA
>> Mailbox is the Identity the draft hopes exposed to the user.  The
>> Mailbox Domain has not been authenticated, only authorized as the Mail
>> Channel will not safely permit such conclusion.  The domain
>> administratively accountable for the MTA remains anonymous beyond the IP
>> address.  There is no identity authenticated through this relationship
>> unless you wish to claim some significance with the MTA IP address.  If
>> there is a problem, what identity will the user report?  If there is a
>> problem, what identity will the MTA/MUA filter or reject?  In each case,
>> the PRA Mailbox Domain is the identity affected.  The problem is that
>> this identity has not been authenticated, but the authenticated MTA IP
>> address is ignored.
>

This is a distinction without much significance.  Restated to suit your
definition would be:

The identity being authorized is (the IP address to send the message on
behalf of) the PRA Mailbox Domain by way of reference to a Mail Channel
prescription of IP addresses.  Of course the Mail Channel prescription
would be administratively controlled by the PRA Mailbox Domain and the PRA
Mailbox Domain resolves the prescribed Mail Channel.

PRA Mailbox Domain -> Mail Channel IP Address prescription -> MTA IP Address

Although the IP address has been authenticated by way of the TCP protocol,
the PRA Mailbox Domain has not been authenticated, as the RFC2822
information is not trustworthy.  The only safe identity resulting when
skiping the steps of authenticating the MTA before resolving authorization
(for sending the message based upon) the Mailbox Domain is the MTA IP
address.  This does not represent much of an improvement with respect to
how reputation can be handled.

Mailbox Domain -> Mail Channel EHLO Name prescription -> Authenticated EHLO

This has the advantage of providing of the EHLO domain being useable with
reputation checks which minimizes efforts needed to track IP addresses of
various entities.  It also has the advantage of allowing the Mail Channel
prescription to be just a simple list of names that do not require
obtaining address lists maintained by other domains to resolve the Mail
Channel. Imagine, one DNS lookup and you're done. : )

>>> EHLO-based schemes:
>>>
>>> Identity:  The identity of a sending MTA is its EHLO name.
>>>
>>> Authentication:  Various scheme to determine whether the EHLO name that
>>> an SMTP client sent is true.
>>
>> The goal of CSV is to ensure a consistent and simple scheme
>> authenticates and verifies MTA authorization.  The identity is the EHLO
>> domain as the message broker.  This authenticated identity can be held
>> accountable.   The Sender-ID identity as represented by the PRA Mailbox
>> Domain has not been authenticated as this requires unverifiable
>> assumptions made with respect to Mail Channel. Bug.
>>
>>> Authorization:  Depending on the scheme, there might be none.
>>> Otherwise, there might be a scheme to determine whether the sending MTA
>>> is authorized by its domain owner to be an SMTP client.  There is no
>>> authorization of individual messages.
>>
>> As I said, CSV provides both MTA authentication and authorization.  This
>> was the goal of the MARID charter. : )
>>
>>> The SenderID series of documents is based on an explicit decision to
>>> pursue the first world-view; the fact that it doesn't do the second is
>>> not a bug.
>>
>> Not authenticating the identity you wish everyone to hold accountable is
>> a bug in this logic.  By allowing an "open-ended" record to exist, this
>> process becomes an exercise in futility, as not even the IP address of
>> the otherwise anonymous MTA is checked.  Such "open-ended" records leave
>> open the door for endless spoofing.  Sender-ID's false assumptions of
>> identity trustworthiness will ensure great potential for harm. : (
>

Could I expect a clarification that reputation is not to be based upon the
PRA Domain, but rather the IP address of the MTA?

-Doug

---

From: <[email-masked]>
Date: Sun, 29 Aug 2004 18:22:04 -0400

On Fri, 27 Aug 2004 19:15:31 -0400, John Leslie <[email-masked]> wrote:
>  ...

This might usually work, but what do you do about the exists and ptr
mechanisms?  In general there is no practical and 100% reliable way to
produce a list of IP addresses authorized by an SPF2 record.

David

---

From: John Leslie <[email-masked]>
Date: Mon, 30 Aug 2004 16:13:20 -0400

> produce a list of IP addresses authorized by an SPF2 record.

   I didn't want to get into that level of detail -- and I especially
don't want to tell reputation services how to run their business...

   But you are correct to note that exists and ptr are too close for
comfort to the +all mechanism. IMHO, one would have to treat them as
"+all" unless you have access to a large enough corpus of actual
queries and replies to limit the set of IP addresses apparently
authorized. (I don't believe monte carlo techniques are workable.)

   How large "large enough" is, I leave as an exercise to the student.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2004 14:27:34 -0700

> produce a list of IP addresses authorized by an SPF2 record.

Evaluating against a currently available IP address blacklist, for
moving from an address scheme to a name scheme, by transferring existing
address information found published in SPF2 records is not possible.  If
there was a black-listed IP address that authenticated as being within
the Sender-ID mail-channel, then that name might be added to a RHSBL. 
Without other confirmation, this would erode reasons for using names
rather than addresses.  Most would drop the connection and not care what
the Sender-ID identity was or whether the MTA authenticated. 

To build upon the IP address blacklist and correlate to a name can not
make use of the SPF2 records directly.  One can not trust the ownership
of addresses published in the SPF2 records.  Building information from
an address black-list based upon what is published in SPF2 records is
meaningless. Publishing addresses has demonstrated nothing with respect
to being administratively responsible for them.  Conversely, obtaining
this address information from complex SPF2 records is impossible without
message-based keys to build access labels.  Sender-ID SPF2 records does
not enable a safe correlation between the MTA address and the Mailbox
Domain.

If comparing an IP blacklist and the SPF2 records-

Building:
   A spammer could make themselves appear to be using known good
   addresses, where actually different addresses are actually used by
   means of the labeling mechanism built upon unpublished information
   found only in the message.  This is a good reason why a macro label
   mechanism is bad.  The SPF2 record must be ignored.

Reporting:
   A spammer could make known good addresses appear bad, if the
   published addresses are included in a reputation assessment.  The
   SPF2 record must be ignored.

Sender-ID SPF2 does not allow a safe bridge between IP address
information and domain name information for reputation use.  Spammers do
whatever it takes to gum up the works and that means claiming IP
addresses they don't administer.  As you point out, the actual address
may not be accessible, if reviewed independent of a message. 

The Sender-ID entity could reside behind a transparently intercepted or
shared outbound SMTP server.  This means assumptions regarding this
Sender-ID identity being authentic may be in error. Sender-ID only gives
the appearance of authenticating the sender, and may have the
unfortunate outcome of being a useful ploy to enable spammers to promote
themselves as being validated by this flawed system.  It also means
innocent parties will become "reputation" victims of these ploys.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2004 14:27:34 -0700

Building:

Reporting:

-Doug

---

From: John Leslie <[email-masked]>
Date: Mon, 30 Aug 2004 16:13:20 -0400