Subject: Action items from June 28 jabber

From: John Leslie <[email-masked]>
Date: Tue, 29 Jun 2004 10:27:50 -0400

Andy closed the jabber session with several action items:
] 
] andy: We were given 3 use cases today. It would be good if meng could
]       take his 2 to the list, and jfenton his to the list.
] andy: Then let's let the CSV proponents explain two things for each,
]       1) how CSV handles them, and
]       2) how SPF does not.

   I'm waiting on these.

] andy: Also, I'd like to see a list of current MTA behaviors that would
]       have to be modified for CSV.
] andy: if any

   This email will try for a reasonably complete answer on this.

   The short answer, of course, is the empty list. CSV does not seek to
change how email is done. It does not seek to say anything must be done
differently. (This is why we see it as orthogonal to SPF.)

   Operators of MTAs are free to change nothing; and things will work
about as well as they do now -- until spammers escalate things so that
overly-broad IP blacklists are applied widely and the MTA's IP address
finds its way onto them. Possibly, they'll even be miraculously lucky
and its IP address _won't_ find its way onto any blacklist. ;^)

   If/when they get caught by that kind of problem, they need to ensure
that the EHLO string the MTA uses is a legal domain name (which it
should be already; but I did say _no_ changes were necessary), and that
they can cause a simple SRV record to be placed under that domain.

   Alas, if they waited that long, there won't be time to acquire a
good reputation, so if they want an instant fix they'll have to find
an accreditation service which already has a good reputation; convince
that service to vouch for them; and cause a PTR record to be placed
at the EHLO domain.

   We advise MTA operators not to wait for problems to show up, but
to place the SRV record quickly, to show that they acknowledge
responsibility for the actions of that MTA, and place PTR records
for a few average-or-better accreditation services as well.

   The syntax of the SRV record is remarkably simple: you have the
"target" name, which will be the same as the EHLO string, plus two
bits of information, which for the vast majority of cases should be
set to authorized=yes and list-empty=no.

   There is no reason you _need_ to place any PTR records at all --
unless you've left things to the last minute and need to arrange for
"instant reputation". Reputation services will naturally assign
(over time) good reputations to domains which send enough "ham" and
no "spam".

   And let us not forget the rather significant number of individuals
who already find themselves paralyzed by IP blacklists: they can
place the SRV and PTR records, demonstrating full accountability and
good reputation; and make a convincing case that any receiving SMTP
server that now blacklists them (perhaps because they're using a
cable provider) can simply implement CSV and stop having to respond
to complaints. ;^)

--
John Leslie <[email-masked]>

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 29 Jun 2004 10:49:23 -0400

On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote:
| 
|    Andy closed the jabber session with several action items:
| ] 
| ] andy: We were given 3 use cases today. It would be good if meng could
| ]       take his 2 to the list, and jfenton his to the list.
| ] andy: Then let's let the CSV proponents explain two things for each,
| ]       1) how CSV handles them, and
| ]       2) how SPF does not.
| 
|    I'm waiting on these.

I was actually waiting for you to provide them.  They were
your cases.  If you look at the following transcript, you'll
see that I had to guess because you weren't telling.

[15:41:24] <mengwong> (if jlc gets a spare moment, i'd like
to ask for some detail on the use case where there's an
actual problem between using an SPF record for the PRD and
using an SPF record for EHLO, please)

[15:42:11] <andy> meng, cts
[15:42:40] <mengwong> uh, so, jlc or doug, can you set up a
problem scenario?
[15:42:44] <mengwong> <eot>

[15:43:23] <mengwong> just thought maybe you guys had one in mind.

[15:43:30] <jlcjohn> Quick answer on case with problem:
workers at home using their cable system to send email for
their work domain.

[15:43:55] <andy> Meng, can you work with that?

[15:44:14] <mengwong> lemme see what the EHLO and the MAIL
FROM look like real quick.
[15:44:38] <mengwong> (taking the MAIL FROM to be close
enough to the PRA that SPF Classic and SenderID look the
same in this case)

[15:45:15] <mengwong> EHLO cable-12-23-34-56.cty.cableco.net?
[15:45:20] <mengwong> <eot>
[15:45:51] <andy> john?

[15:45:54] <jlcjohn> Actually, it might be that, or the
cable provider might force use of their server.
[15:45:58] <jlcjohn> <eot>

[15:46:07] <mengwong> ok, so we have two subcases ...
[15:46:22] <mengwong> if the cable provider forces use of
their server, we have EHLO mta4.cableco.net
[15:46:28] <mengwong> MAIL FROM:<[email-masked]>
[15:46:29] <mengwong> ?
[15:46:33] <mengwong> <eot>

[15:46:42] <jlcjohn> OK <eot>

[15:46:58] <mengwong> so mta4.cableco.net has an SPF record,
and work.com has an SPF record ... and ... ?
[15:47:17] <mengwong> and the mta4.cableco.net SPF record is
checked at EHLO time, and the work.com record is checked at
MAIL FROM time ...
[15:48:01] <mengwong> <eot>

[15:48:10] <jlcjohn> What happens when mta4.cableco.net gets
a bad reputation?
[15:48:13] <jlcjohn> <eot>

[15:48:28] <mengwong> then work.com has to set up port 587
with SMTP AUTH
[15:49:01] <mengwong> if the mta4.cableco.net identity has a
bad reputation, then it sucks for the mail sender whether
the checks are being done with CSV or SPF, right?

[15:50:21] <andy> these are two good use cases. perhaps
flushing them out on the list is good.

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 29 Jun 2004 11:11:29 -0400

On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote:
| 
|    The short answer, of course, is the empty list. CSV does not seek to
| change how email is done. It does not seek to say anything must be done
| differently. (This is why we see it as orthogonal to SPF.)

To provide clarity, can you explain if by the above "SPF"
you mean "Unified SPF" or "SPF Classic"?

"Unified SPF" always examines the HELO domain, offers an
authentication status, and gives receivers an opportunity to
perform whitelisting or rejection operations based on that
result.  It does this independent of examination of the
return-path or the PRA.

"SPF Classic" by comparison only performs spoof detection on
the HELO name, and always checks the return-path.

Unified SPF even solves the forwarding problem by allowing a
receiver site to whitelist forwarders by HELO name,
overriding the return-path result.

It appears to me that the set of features offered by Unified
SPF overlaps with the features offered by CSV.  Please
correct me if I'm wrong; my understanding of CSV is
obviously not as good as yours :)

|    Operators of MTAs are free to change nothing; and things will work
| about as well as they do now -- until spammers escalate things so that
| overly-broad IP blacklists are applied widely and the MTA's IP address
| finds its way onto them. Possibly, they'll even be miraculously lucky
| and its IP address _won't_ find its way onto any blacklist. ;^)

The above is also true of Unified SPF.

|    If/when they get caught by that kind of problem, they need to ensure
| that the EHLO string the MTA uses is a legal domain name (which it
| should be already; but I did say _no_ changes were necessary), and that
| they can cause a simple SRV record to be placed under that domain.

The above is also true of Unified SPF, except that the
record is the SPF TXT or MARID record.

|    We advise MTA operators not to wait for problems to show up, but
| to place the SRV record quickly, to show that they acknowledge
| responsibility for the actions of that MTA, and place PTR records
| for a few average-or-better accreditation services as well.

The above is also true of Unified SPF.

|    The syntax of the SRV record is remarkably simple: you have the
| "target" name, which will be the same as the EHLO string, plus two
| bits of information, which for the vast majority of cases should be
| set to authorized=yes and list-empty=no.

The syntax of the SPF record for the MTA is TXT "v=spf1 a -all".

|    And let us not forget the rather significant number of individuals
| who already find themselves paralyzed by IP blacklists: they can
| place the SRV and PTR records, demonstrating full accountability and
| good reputation; and make a convincing case that any receiving SMTP
| server that now blacklists them (perhaps because they're using a
| cable provider) can simply implement CSV and stop having to respond
| to complaints. ;^)

Yes, it would be a great benefit to the wrongly-blacklisted
folks if they could positively accept responsibility at the
HELO or return-path levels and thereby override
provider-based negativity.

This argument is made at

  http://spf.pobox.com/slides/unified%20spf/0429.html

if we replace "MTAMark=no" with "listed on DUL blacklist".

cheers
menmg

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Jun 2004 16:55:35 +0100

> set to authorized=yes and list-empty=no.

It might be the case that the EHLO domain is a CNAME, in which case the
SRV target should be same as the CNAME target not the EHLO domain itself.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
RATTRAY HEAD TO BERWICK ON TWEED: SOUTHWEST OR WEST 3 OR 4, BACKING SOUTH 4 OR
5. FAIR, THEN RAIN OR SHOWERS. MODERATE OR GOOD. SLIGHT.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Jun 2004 09:51:57 -0700

> result.  It does this independent of examination of the

Details? Where is the draft?

> overriding the return-path result.

This could be a bad idea.  How is the HELO name authenticated and
authorized?

> obviously not as good as yours :)

Is there an Internet Draft on the Unified SPF.  It is hard to do a
meaningful review with so many details missing.

Also there is yet to be a Internet Draft that documents the current
"Core" documents.  There is also a very telling item missing.

What do you expect to be the average number of indirections per SPF
record?  What is the maximal depth of recursion?  

How is path permissions differentiated from administrative ownership?

> The above is also true of Unified SPF.

The major problems result from weak transversal authorization determined
by SPF.  You may consider these the same, but the details entailing such
is important.  ACCREDITATION can not be administered if the
Authentication and Authorization are not confirmed for unknown, in
addition to that determined to be accepted.  It is apparent that SPF
only provides weak path assurance regarding an accepted message.  The
assurances for either unknown or rejected messages are nil.  That is a
huge category left open.    

> record is the SPF TXT or MARID record.

Where is the draft?  I do not think these are equivalent and making such
claims remains allegation without substance.

> The above is also true of Unified SPF.

Again, this overlooks details involved to establish administrative
ownership, authentication and authorization.

> The syntax of the SPF record for the MTA is TXT "v=spf1 a -all".

What does this say exactly?  Go look for an address?  I would not call
this as being the same.  In addition, these statements are not about
which domain administers the mail server, this makes a statement about
what domains may transverse this mail server.

> provider-based negativity.

It is also equally important to assess accountability properly.  Do not
force individuals to accept accountability for every machine they must
list to allow their mail to transverse these other machines.

>   http://spf.pobox.com/slides/unified%20spf/0429.html

A slide show provides no details and therefore provides no additional
information.

-Doug

---

From: Roy Badami <[email-masked]>
Date: Tue, 29 Jun 2004 18:27:28 +0100

>>>>> "Tony" == Tony Finch <[email-masked]> writes:

    Tony> It might be the case that the EHLO domain is a CNAME

Though, strictly, this is illegal according to RFC821/2821.

	-roy

---

From: Greg Connor <[email-masked]>
Date: Tue, 29 Jun 2004 11:39:47 -0700

> assurances for either unknown or rejected messages are nil.  That is a

Doug- I couldn't understand this paragraph, and I think it's important to 
understand what you're saying here -- some of the keywords suggest that you 
feel it's an important point.

Here are some followup questions.
Q. What is a "transversal authorization?"  What makes one weak vs. strong?

Q. Regarding this sentence, I couldn't quite unwind what you meant, though 
I am probably close to understanding:
> ACCREDITATION can not be administered if the
> addition to that determined to be accepted.
I understand this to mean "If the result is "unknown" then accreditation 
cannot be applied.  I would take that as a given, but I believe that is the 
same with both SPF and CSV.  Is this meant to imply that the existence of 
an "unknown" state itself is a defect?  If I understand correctly, CSV also 
has an "unknown" state.  In both proposals, I believe the domain owner has 
to make sure a PASS or "known good" result is received before honoring any 
accreditation, right?   Anyway, let me know if you meant something else 
here that I am not understanding.

Q. Regarding these two sentences, please clarify:
> It is apparent that SPF

Is this meant to state that a CSV "authorized" result is stronger than an 
SPF PASS result?  Why do you say that?  Both are comparing an IP address to 
a DNS record, and in that regard seem to provide very similar features from 
the technical side.  Do you mean that there is a difference in how the 
records will be interpreted by users?  Is it because of the way the drafts 
are written?  I'm trying to understand if it is a difference in the design, 
or just in how it is used by implementors and explained to users...

Also what do you mean by "The assurances for either unknown or rejected 
messages are nil".  What assurance does CSV provide if the status is 
unknown?  If the status is reject/fail, doesn't that mean reject the 
message, and isn't the "strength" of that assertion the same for both SPF 
and CSV?

Thanks
gregc

--
Greg Connor <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Tue, 29 Jun 2004 17:06:05 -0400

I'd like to apologize up-front for the length of this post. Feel free
to skim it if you think I'll never get to the point. (I'm likely to
have guessed wrong on some details of SPF anyway.)
 
Meng Weng Wong <[email-masked]> wrote:
>|] 
>|] andy: We were given 3 use cases today. It would be good if meng could
>|]       take his 2 to the list, and jfenton his to the list.
>|] andy: Then let's let the CSV proponents explain two things for each,
>|]       1) how CSV handles them, and
>|]       2) how SPF does not.
>... 
>... 
>...
>...
>...

   This case being simpler, let's start with it.

   CSV will take the EHLO mta4.cableco.net, and do both a reputation
check (out-of-band) and a SRV query on _client._smtp.mta4.cableco.net.
Hopefully that will return authorized=1 and list-empty=0, and hopefully
the IP address will match one on the list returned. Thus authorization
will be established. There's a pretty good chance that reputation will
come back OK, because reputation services hate to turn off the main
mailservers of cable providers.

   But, IMHO, the cableco.net reputation is unlikely to be good
enough to bypass further checks. For the sake of argument, let's say
the receiving SMTP server chooses to do SPF checks against the
RFC2821 MAIL FROM.

   This, alas, will flunk if work.com publishes a SPF record which
does not include mta4.cableco.net. In practice, cable providers have
multiple outgoing MTAs, and work.com will probably have to use the
"include" mechanism for a recursive query or a "redirect" modifier
to tail-recurse to cableco.net. (More likely the former, since they
are likely to have different home-workers at different providers.)
Hopefully, this will all result in a SPF "pass".

   Now we come to the reputation question. The reputation queried
will be work.com. Let's break here, and come back to it after
discussing what SPF-without-CSV will do.

   SPF-without-CSV may or may not evaluate the EHLO. (I hope I'm
right there: I haven't seen a SPF draft that says otherwise;
please correct me, Meng, if I'm wrong.) If it does, I would expect
it to yield a "pass", no different from CSV.

   SPF-without-CSV will evaluate the MAIL-FROM, and the results
will be the same as for the with-CSV case. Hopefully that gets us
back to where we broke off: the reputation question.

   The difference between with-CSV and without-CSV will show up in
the reputation-service ratings of work.com. In the with-CSV case,
reputation-service rating of the EHLO cases will always accurately
correlate with the CSV semantics of assuming responsibility, and
_if_ (a big if, as things appear right now, but I'm an optimist!)
cableco.net ever acquires a good enough reputation on EHLO, work.com
will no longer have to include it by reference in its SPF record,
eliminating the risk of work.com's reputation being sullied by a
cableco.net lapse.

   Please understand that the social pressure which inflates the
cableco.net rating will _not_ similarly inflate the work.com rating.
Reputation services will feel much freer to downgrade work.com, and
leave it downgraded longer.

   I fully agree, BTW, that this difference is subtle, and may not
be worth worrying about. But we're discussing a case which shouldn't
happen in the first place: the case where cableco.net blocks both
port 25 direct sending and port 587 submission.

> [15:45:15] <mengwong> EHLO cable-12-23-34-56.cty.cableco.net?
and
> [15:46:28] <mengwong> MAIL FROM:<[email-masked]>

   (I think that exact case unlikely, and will describe it only on
request: the EHLO string must be programmed, and IMHO it is unlikely
that the worker would program that funky cableco string.)

   Let me instead describe:

EHLO mail4.work.com
MAIL FROM: [email-masked]

   CSV will query the reputation of "mail4.work.com" and query for
a SRV record at _client._smtp.mail4.work.com. This will return
authorized=1 and list-empty=0, and the IP address will match if
the DNS record is updated to match the latest IP-shuffle of the
cable provider. (If it hasn't we'll get timely warning when <worker>
tries to send mail from home.)

   The reputation will match the actual responsibility for operating
this MTA: good if it's operated carefully, and bad if it's not.

   That's important! There's a real incentive to operate carefully.
Let's assume that <worker> does operate carefully. In that case the
reputation report will be excellent, and the receiving SMTP server
will be programmed to skip the SPF check on MAIL FROM.

   But if there is to be a (later) SPF check, work.com has no need
to recursively include domains over which it has no control, and
can use tricks like the "exists" mechanism to track potential abuse,
or simply leave the record open with ?all if no problems show up.

   Conversely, SPF-without-CSV MAY check EHLO or may not. Hopefully
if it check, it'll pass. But reputation services won't have a clean
division of responsibilities, because work.com will be forced to
use recursive includes. work.com's reputation is likely to suffer
when cableco.net suffers a lapse.

   And, SPF-without-CSV _will_ check MAIL FROM, with the same issues
as above.

   If _this_ difference seems subtle, I must not have explained it
very well, because here we have the difference between accurate
reputation matched to clean semantics of CSV, versus reputation
sullied by the not-too-great reputation of a much larger entity,
with semantics so confused that I don't believe any reputation
service will be able to sort out the difference between "accept
responsibility for the actions of this MTA" and "this MTA is not
under our control, but may send our email anyway".

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Jun 2004 14:30:18 -0700

> feel it's an important point.

I am working on a more complete response but felt there was a demand
that something be said immediately...

> Q. What is a "transversal authorization?"  What makes one weak vs. strong?

There are undefined boundaries where SPF/CID _may_ be checked.  Headers
are easily forged and should there be a machine internal to an undefined
administrative region erroneously accepting mail, this puts every
message carried in question.  I would call this a weak from of
identification.

What identity is used to assert accountability?  Due to this weak from
of identity, SPF/CID _MUST_ never be used to assert accountability.  If
mail was injected somewhere inside a nebulous region devoid of SPF/CID
checks, how is this detected?  Are those spoofed to be soiled by a
machine somewhere not tied down properly?

> > ACCREDITATION can not be administered if the Authentication and
> > Authorization are not confirmed for unknown, in addition to that
> > determined to be accepted.

> same with both SPF and CSV.

If _everyone_ fully implemented SPF, there would still be the category
Unknown.  If everyone implemented CSV, this category would no longer
exist.  In addition, the identity established using CSV provides a means
to apply accountability.  Those being spoofed would not be impacted,
just the administrative domain that failed to secure access to _all_
their machines.  

> Is this meant to imply that the existence of an "unknown" state itself
> is a defect?  If I understand correctly, CSV also has an "unknown"
> state.  In both proposals, I believe the domain owner has to make sure
> a PASS or "known good" result is received before honoring any
> accreditation, right?   Anyway, let me know if you meant something
> else here that I am not understanding.

Yes, there would be an unknown state, but only for those that failed to
implement CSV.  In the normal operation of SPF/CID, an unknown state
must be allowed as an escape for those unable to publish a comprehensive
list of domain and address relationships. SPF/CID is unable to scale for
a comprehensive list, so by design there exists the unknown state.  I
venture to say that SPF/CID may not handle even a conservative amount of
publishing of these relationships.

The full complexity of these relationships may become more pronounced
once SPF/CID checks are widely implemented and more domains attempt to
"close" their lists due to spam attacks.  Attacks deployed against
hapless domains that would otherwise wish to publish more but are unable
to comply listing all points of mail access.

> > It is apparent that SPF only provides weak path assurance regarding
> > an accepted message.  The assurances for either unknown or rejected
> > messages are nil.  That is a huge category left open.
> 
> SPF PASS result?

The area of policy only applies to the MTA server and not to users of
mail.  Reputation must only apply to the administration of policy for
the MTA.  Reputation can not scale to the user nor should a mail stream
be considered secure to base assumptions about where a message was
derived.  Who gets credited, should the published permitted path for a
message determined abusive traverse many domains?  There is virtually no
cost associated in creating a user.  There is some cost, albeit small,
for creating a domain.

> Why do you say that?

Limiting the results of a check to answer just the question regarding
the channel and NEVER the message, then it is possible to ensure a valid
answer. 

> Both are comparing an IP address to a DNS record, and in that regard
> seem to provide very similar features from the technical side.  Do you
> mean that there is a difference in how the records will be interpreted
> by users?

These lists are not technically the same.  One is a list to correlate
domains and addresses to express permitted traversals, the other is a
list of servers administered by a domain.  These sentences include many
of the same words, and may even include some of the same addresses, but
these lists are not the same nor are they intended to answer the same
question.  

> Is it because of the way the drafts are written?

There is a major difference in paradigms where a slight of hand changing
a word here and there will not mollify these differences.

Publishing in DNS TXT records all mail domain paths using a technique of
linked records is a wholly different goal.  I would question the
suitability of DNS for this.  DNS is well suited to answer the question
what is the list of addresses associated with a EHLO domain which
provide both Authorization and Authentication with perhaps just an SRV
record.      

> I'm trying to understand if it is a difference in the design,  or just
> in how it is used by implementors and explained to users...

The difference is where the problem is addressed. Identify by the name
of the domain attempting to inject mail into the system and stop it
there rather than looking at each message.  Each message may easily pass
muster with SPF/CID, in fact, it should be expect this to be the case.  
> message, and isn't the "strength" of that assertion the same for both SPF 

Should CSV be fully implemented, there will be no unknowns as opposed to
SPF/CID.  If there is any abuse discovered, the accounting of this abuse
will be accurately applied to the domain and never is the header of a
message trusted.  The ability of user to forward mail or use their
favorite access point to send mail containing their return address
remains unchanged.  It does however mean for domains to protect their
accreditations, they must be responsive to abate abuse.

To abate identity fraud, I strongly suggest considering the use of
Fenton's "Identified Mail" proposal.  This technique scales and does not
threaten the integrity of DNS and Mail in the process.  Users will still
be allowed the freedom to send mail but commerce can be protected in a
very strong way against fraud regardless of the path taken.

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 29 Jun 2004 15:29:08 -0700

On 6/29/2004 7:49 AM, Meng Weng Wong sent forth electrons to convey:

>your cases.  
Yeah, looks like they were mis-assigned, and no one noticed.
Anyway, I'd suggest that the lively thread about DDoS attacks presents a 
situation that CSV handles well, and SPF doesn't handle as well.
How poorly it is handled merits further discussion.

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 29 Jun 2004 18:52:57 -0400

On Tue, Jun 29, 2004 at 03:29:08PM -0700, Matthew Elvey wrote:
| Yeah, looks like they were mis-assigned, and no one noticed.
| Anyway, I'd suggest that the lively thread about DDoS attacks presents a 
| situation that CSV handles well, and SPF doesn't handle as well.
| How poorly it is handled merits further discussion.

It seems to me the DDOS attacks we have reviewed so far
pretty much boil down to:

SECURITY CONSIDERATIONS

  We take it as a given that malicious entities control
  large distributed networks of 0wned machines, in the six
  to eight figure range.  These machines are compromised
  workstation-grade machines that belong to ordinary
  end-users on broadband connections.  They are generally
  referred to as zombies.

  Malicious entities who have philosophical objections to a
  given technology may attempt to dissuade people from
  adopting that technology by mounting distributed
  denial-of-service attacks on adopters.

  The most elegant way to mount such an attack is to
  contrive a scenario in which the technology itself plays a
  part in the resulting denial of service.  If the attack
  does not affect those who do not adopt the technology, and
  only hurts those who do adopt the technology, it gives
  adopters incentive to abandon the technology.  Such an
  auto-targeting attack can be easily executed using zombie
  networks.

  Technologies which are more complex tend, in general, to
  be more easily attacked in this way than technologies
  which are simpler.

  However, the elegant attack is not the only attack.  A
  malicious entity may identify adopters of a given
  technology in an initial pass, and use the zombies against
  those adopters directly.  The connection between the
  attack and the objective (discouraging the technology) can
  be made when an attacker claims responsibility for the
  attack.

  Both the elegant and the brute-force attacks are feasible
  against any open protocol.  The only way to avoid these
  attacks completely is to retreat to a "private club"
  model, in which nodes do not communicate with other nodes
  if they have not previously established a trust
  relationship.

  A midway position between total openness and a "private
  club" involves the use of reputation services.  If a
  protocol endpoint tests new connections against a
  reputation service before engaging more deeply in protocol
  operation, attacks can be mitigated.

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 29 Jun 2004 16:09:31 -0700

On 6/29/2004 2:30 PM, Douglas Otis sent forth electrons to convey:
 > <something important>

I struggled to understand Doug's post for a few minute, and then 
considering the RHS of Doug's email address ("mail-abuse.org") made it 
all clear.

Put yourself in the shoes of an RHSBL maintainer for a moment.

With CSV, if a domain has authorized its use in HELO for an IP, it is 
reasonable to blacklist said domain for such authorization when it 
results in spam.
And a blacklist of such domains could be quite effective at separating 
ham and spam with few FPs and FNs.

With SPF, if a domain has authorized its use in any of the myriad ways 
that SPF requires it authorize its use, then it's much less reasonable 
to blacklist said domain for such authorization when it results in 
spam.   A blacklist of such domains would be much less capable of 
separating ham and spam with few FPs and FNs.

Here's an example:  there is no MTA that does a HELO elvey.com.   Mail 
from users at elvey.com is sent through (among others) rr.com and 
fastmail.fm.
rr.com and fastmail.fm will have to publish CSV records, but elvey.com 
won't.  All three will have to publish SPF records.

elvey.com.              7201    IN      TXT     "v=spf1 a mx 
ip4:63.195.86.147 ip4:66.111.4.0/24 include:webcom.com include:rr.com 
include:pacbell.net include:nextbus.com include:messagingengine.com ?all 
match_subdomains=yes"
What am I supposed to do if zombies on pacbell.net and rr.com start 
forging mail  from elvey.com?  Is MAPS going to point out that it's 
listed me for having a loose SPF record? Proably.  So I must tighten up 
my SPF record?  How, exactly?
Assume that just 5% of all domains are in the same kind of situation.  
Basically, include:rr.com, include:pacbell.net, etc. need to be removed, 
and I need to set up smarthosts and walk ALL the users using rr.com and 
pacbell.net through changing their MUA configurations.  That would suck!

(Assume for the moment that rr.com, pacbell.net, etc. do publish SPF 
records)

I suspect that the scenario I've described is of the kind that Doug is 
worrying about.

---

From: Roy Badami <[email-masked]>
Date: Wed, 30 Jun 2004 01:02:59 +0100

>>>>> "Douglas" == Douglas Otis <[email-masked]> writes:

    Douglas> What identity is used to assert accountability?  Due to
    Douglas> this weak from of identity, SPF/CID _MUST_ never be used
    Douglas> to assert accountability.  If mail was injected somewhere
    Douglas> inside a nebulous region devoid of SPF/CID checks, how is
    Douglas> this detected?  Are those spoofed to be soiled by a
    Douglas> machine somewhere not tied down properly?

Having been skimming this thread, and not entirely understanding what
it was about, I'll have to say I think I agree with this point,
although I don't think it's very clearly stated.

I'm starting to understand why CSV could be potentialy valuable...

NB: The following discussion relates to the drafts that have been
submitted to this WG, and to the published SPF ID
(draft-mengwong-spf-01).  I'm aware of some discussion on the SPF list
and subsequently here about "Unified SPF" but no ID yet exists to my
knowledge; I'll leave my comments about that till the end...

Both draft-mengwong-spf-01 (SPF) and draft-ietf-marid-core-01
(SenderID) are to do with authenticating *messages*.  If you receive a
message that fails the SPF or SenderID checks, you know the *message*
is forged, but you know nothing about who forged it.  The fact that an
MTA sends you a message that fails SPF/SenderID checks tells you
nothing about the propriety of the MTA that sends it to you; just that
a forged message was injected into the mailstream at some point, and
that MTA (quite possibly perfectly innocently) happened to attempt to
deliver it to you.

draft-ietf-marid-csv-* authenticates the sending MTA directly (but it
doesn't authenticate the message in any way); if you get CSV
authentication failures, you know that it's the immediate upstream MTA
that's spoofing.  But the fact that the MTA is genuine doesn't prove
that the message is genuine.

What does this gain you in itself?  Probably not much.  It wouldn't be
much effort for spammers/phishers/whatever to give a valid HELO
identity in a throwaway domain registered for that purpose.

But coupled with reputation/accreditation services, it becomes more
valuable.  Doing reputation/accreditation by IP address is problematic
at best -- it interferes with things like network renumbering,
deploying additional MTAs, etc, and has problems when IP addresses are
reallocated to other entities.

Having an authenticated name for the delivering MTA is a more flexible
way of attaching reputations/accrediation to MTAs than the IP
blacklists/whitelists (largely blacklists) we currently use.

And filtering at that level is clearly useful.  Most of us use IP
blacklists.  And we're now living in a world where open relays no
longer account for the majority of spam.  Most spam is now direct to
MX or delivered via open proxies (in both cases with compromised
machines often being used).  So establishing reputation at the
delivering MTA level would seem to be a valuable tool, and having a
mechanism for doing so without requiring that ISPs never renumber
their networks for fear of losing their reputution is clearly a good
thing.

(Obviously reputation at this level is a defense against open relays
too, it's just that they're no longer the main threat).

It seems to me that SPF/SenderID and CSV solve very different
subproblems of the problem space that this WG is interested in, and in
particular that they may end up using very different notions of
reputation/accreditation.

In a scheme like SPF/Caller ID/Sender ID you're looking at reputations
of e-mail addresses (or at least their domains).  Does this domain
originate mail that is legitimate, or does it originate spam?  People
blacklist/whitelist now on MAIL FROM and From: but it's problematic
because it's easily forged.  If you can prove an association between
the message and the domain, such blacklisting/whitelisting becomes
more reliable.

Also, at least some of the proposals (namely Caller ID and the Sender
ID) are potentially very useful components in an anti-phishing
strategy -- ie validating the domain that is displayed to the end user
-- even if such strategies also require MUA support.  And
anti-phishing is clearly something that many people want.

In CSV/CSA you're looking at reputations of originating hosts.  Is
this a well run MTA, or is this some random bot, proxy or open relay
that's opening an SMTP connection to me?  Granted the fact that it's a
well run MTA doesn't prove that forged messages or spam won't pass
through it, but in the world we live in a very small proportion of
unwanted mail is originated from well-run MTAs, so reputation at that
level certainly seems valuable.  Most of us do this already based on
IP blacklists.  Blacklisting/whitelisting (particularly when you get
to whitelisting) on an authenticated name of the host seems far more
flexible.

Based on the above, which I realize might involve a misunderstanding
of one or both proposals, it seems to me that Sender ID and CSV
attempt to tackly essentially unrelated subproblems within the MARID
problem space.

I think a lot of the confusion in this and other threads stems from
the fact that the two proposals tackle different subproblems, and many
WG participants are essentially focussed on just one of them.

In fact, it seems to me that the models of reputation and accrediation
services that might evolve within these two problem areas are
potentially quite different.

It also seems to me that Sender ID and CSV can be deployed
independently; both publishers and checkers can decide to implement
one, the other, or both.

Given that, it's not clear to me that it's appropriate to burden CSV
with the complexity of an SPF record, since people may wish to deploy
CSV without Sender ID.

So, in answer to the question:

   - Due 2004-07-02: Decide if CSV is complimentary, parts to be 
     incorporated, or dropped.

My current gut feeling is that this WG should advance
draft-ietf-marid-core/submitter and draft-ietf-marid-csv-* to PS
without trying to unify them technically.  I think the only
unification that should happen is (if feasible within the timescales)
is in terms of a unified intro/rationale document that describes the
framework in which both exist.

Part of the reason for my position is that they address different
subproblems of the MARID problem space, and that I don't think there
is any clear technical benefit in unifying the record formats, given
the simplicity of the CSA record.

There are also pragmatic reasons for this position.  This WG is
working on a very tight schedule, and it also is treading into
unchartered territory.  Despite the SPF adoption to date, nothing has
been implemented on a large scale (current SPF deployement is still,
in reality, a drop in the ocean) and none of us really knows how this
will pan out in practice.  We're not going to get this right first
time, however hard we try; we have to accept that.  Whatever this WG
proposes, I'm sure that there will be much more work to do in the
future (either by this WG or a successor) in the light of operational
experience of those proposals.

Given that the groups of people persuing the Sender ID and CSV problem
spaces are largely disjoint, keeping the proposals largely independent
seems like the most efficient use of this WG's time; and it strikes me
that attempting to unify them technically just for the sake of it is
likely to consume much WG effort for little or no technical benefit.
Only operational experience will tell us the value of MARID in these
two problem spaces, and until we have that, I think a 'unified theory
of MARID' is premature.

Ok, now the promised brief comment on 'Unified SPF':

I'm coming the to conclusion that Sender ID shouldn't be extended to
check the HELO.  SPF checked it only for mail from <>; Sender ID if
I'm not mistaken doesn't check it at all.

But the semantics of checking HELO are very different from what
SPF/Sender ID set out to do.  And it's not clear to me that the
reputation/accreditation services will work in the same way.  Or that
the same reputation/accreditation services will be interested in
dealing with both problem spaces.

The only reasone why SPF checked the HELO (as I see it) was to close
the gaping hole left by mail from <>; CSV seems a better solution to
that, so leave it out of Sender ID.

Sorry to have bored you all with such a long post; hope this makes at
least some sense...

      -roy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 29 Jun 2004 21:47:42 -0400

On Jun 29, 2004, at 8:02 PM, Roy Badami wrote:

> Granted the fact that it's a
> level certainly seems valuable.

I have in my notes an interesting tidbit from the MAAWG meeting in DC:
Carl Hutzler of AOL said that >70% of spam comes through the mail 
servers of ISPs.

-andy

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Jun 2004 10:42:01 +0100

On Tue, 29 Jun 2004, Matthew Elvey wrote:
>
> Here's an example:  there is no MTA that does a HELO elvey.com.   Mail from
> users at elvey.com is sent through (among others) rr.com and fastmail.fm.
> rr.com and fastmail.fm will have to publish CSV records, but elvey.com won't.

You would probably want to populate your zone with negative CSV records to
ensure that all hosts are explicitly unauthorized to use your domain,
rather than neither authorized not unauthorized.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST FITZROY: NORTH OR NORTHWEST 4 OR 5, OCCASIONALLY 6 IN EAST. FAIR.
MAINLY GOOD.

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Jun 2004 11:05:14 +0100

> WG participants are essentially focussed on just one of them.

I think the reason for this confusion is the layering confusion in
designated sender schemes. CSV is purely focussed on authenticating the
SMTP client, and only checks a single hop of the multi-hop message path;
it doesn't attempt to deal with end-to-end authenticity. Designated sender
schemes aim to check that the message was sent by the purported sender
(which is an end-to-end property, not hop-by-hop) but it does this by
checking the last hop, not by checking the original end-point. If you're
focussing on the last hop the two schemes can appear to be doing the same
thing, but you can see they are not by considering the layers.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. RAIN IN EAST AT
FIRST, OTHERWISE SQUALLY SHOWERS. MODERATE OR GOOD.

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 29 Jun 2004 11:11:29 -0400

This argument is made at

cheers
menmg

---

From: Greg Connor <[email-masked]>
Date: Tue, 29 Jun 2004 11:39:47 -0700

Thanks
gregc

---

From: Andrew Newton <[email-masked]>
Date: Tue, 29 Jun 2004 21:47:42 -0400

-andy

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 29 Jun 2004 10:49:23 -0400