Subject: Re: SIQ, SPF, BATV, etc.

From: Frank Ellermann <[email-masked]>
Date: Sun, 01 Jan 2006 07:31:28 +0100

Douglas Otis wrote:

> The BATV draft seems to be a good start.  Perhaps it can be
> further simplified.  Could this satisfy both camps?

Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821,
or something else ?  For the former I'm lost, I read the now
expired BATV draft, and for SES all I know is that they can
optionally use the SPF "exists"-mechanism somehow resulting in
1123 5.3.6(a) compatibility.  I wasn't very interested because
IIRC it worked only for domains with their own name server (?)

> There is no question that better conventions are needed when
> dealing with auto-responses.  Conventions that limit the
> alternative to MAILER-DAEMON@, instead of a null address
> could be helpful.

In 2004 SC still did not allow to report backscatter as abuse,
my "rule collection" to extract this crap from all other spam
was constantly growing until "my" spammer figured out SPF FAIL.
One of these rules was MAILER-DAIMON@ (sic ;-)

Yes, it could be helpful for applications behind a smart host
or non-2476bis-MSA not supporting MAIL FROM:<>   But that's a
potential FUSSP-trap.  Additionally you'd have to s/MAY/SHOULD/
in 3834 section 3.3.  The latter might be possible without much
ado, and I'd like a 3834bis as DS.  Two implementation reports,
anybody ?

> could be introduced into a BATV expectation list, when needed

3834 lists owner-* and *-request in addition to MAILER-DAEMON.

>> Hardcore "bounces-to" fans won't use BATV, they already hate
>> the more flexible SPF.

> This is not an issue for BATV.  BATV does not depend upon any
> third-party adoption.

You can't use "your" Return-Path on any route you like if the
returned messages are rejected by BATV.  That's the same issue
as for SPF, only more restrictive:  SPF allows to aggregate
unrelated sending routes per domain.  BATV works for one and
only one MON (all its MSAs plus the corresponding MRN).  And I
don't see how a "bounces-to" fan could accept this.

> As part of the BATV draft, when the message is delivered,
> removing the tag or obfuscating the BATV <glob> section in
> what is normally prefixed as "Return-Path:" would also be a
> helpful practice.

IMHO that would break vacation-like 3834-applications, their
auto-responses would be rejected by the originator's BATV-MRN.

It's not that I don't like BATV, but it can't substitute SPF
FAIL.  For those who can do both they should certainly try it.

You're not talking about creating BATV local parts in the MUA,
or are you ?  That would be another FUSSP trap.  IIRC the BATV
idea is to replace the local-part of the MAIL FROM at the MSAs
(or mail-outs behind an MSA), and undo that modification later
for the local part of the RCPT TO at the MXs (or MDA) in the
case of "returned" mails, invisible from the sending MUA's POV.

While the MXs reject all other identified bounces, that's the
purpose of this coordinated MON + MRN effort known as BATV.

>> doesn't address the real problem, the forged Return-Paths.

> On the contrary, BATV eliminates the forged return-path as a
> delivery strategy.

Sorry, I fail to see how, not without "call-back-verification"
at the side of the primary spam victims.  Or an equivalent pre-
abuse-address-quality-control-test by the spammer.  The latter
strategy worked for SPF FAIL because professional spammers use
SA for their QoS-tests (1).  Without knowing SA I doubt that it
supports "call-back-verification", that's rather expensive, or
isn't it ?

[1: source = my crystal ball when "my" spammer stopped to abuse
    "my" addresses soon after SA 3.0 supported SPF, 2004-09-01]

>> With SPF FAIL this crap can be rejected a.s.a.p.
[...]
> "As Soon As Possible" is not better than "As Painless As
> Possible." : )

Well, the "SPF-opposition" is apparently determined to let SMTP
die while preserving 1123-5.3.6(a) "251"-forwarding, and a dead
SMTP won't feel the pain.

Most SPF FAIL policies are a "die, spammer, die" voice against
1123 5.3.6(a).  Excluding a few who publish -all without RTFM.

> Rather than compiling lists of addresses for outbound servers
> for a set of domains by issuing dozens of DNS lookups,

NAK, still two lookups in my case before you have either PASS
or FAIL.  In theory one query would do, but I won't bother my
ISP with this minor improvement before SPF is at least a PS.

For an SES-exists variant it might be also two DNS queries (?)
No idea what the average is, but it would surprise me if it's
more than six, let alone one dozen, or your "dozens".

Some of the most complex sender policies are huge ISPs sending
lots of mail, and then you'd get many answers from your cache.

>> 1123 5.3.6(a) does not work as expected in its own post-821
>> "bounces-to" world.

> This is a problem only when a third-party attempts to verify
> the return-path.

What they actually do is use it as specified for their crappy
"accept-then-bounce" setup.  That was "state of the art" until
2001 as documented in 2821.  Won't make it into any 2821bis.

Verification with SPF started 2004, only a minority does this.
Fortunately the spammers can't determine who checks SPF without
rejecting FAIL, and therefore they're forced to avoid SPF FAIL
protected addresses.  Besides we're not yet in the phase where
spammers are forced to pick their Return-Path depending on the
target.  Except from the obvious idea to use a plausible ccTLD
matching that of the recipient in localized spam.

Or the stoneage From = To tricks, I consider that as incentive
for SPF FAIL publishers to join the "SPF checking elite" (that
doesn't include my ISP, maybe they'll see the light in 2006 ;-)

> Prevent the bounce delivery strategy from being successful,
> and soon it will not be used.  BATV prevents this strategy
> from being successful without changing email practices.

IMO it's in most cases no "delivery strategy".  2821-DDoS and
Joe Jobs excluded I think the spammers just abuse any address
surviving "call-back-verification".  They really try to reach
their primary RCPT TO victims, not the secondary MAIL FROM.

And BATV does nothing for the existing primary victims, it
only blocks most "user not found" + "user over quota" bounces
at the MX of the secondary victim.  At this time the spam was
already accepted by an MX of the primary victim, rejected by
the MDA, and queued for a bounce message in a "mail out" of
this primary victim.  At this time all other spams abusing the
same MAIL FROM domain of the secondary victim are _delivered_
to all existing primary victims (minus "over quota" cases).

BATV has none of the SPF FAIL advantages for primary victims,
it only blocks some of the backscatter.  BATV does nothing
wrt obscure C/R systems.  Behind an SPF PASS C/R systems might
actually work as expected for the first time.  Behind an SPF
PASS the complete SMTP up to 3834 works again.

BATV doesn't have this feature.  BATV catches 100% of all bogus
bounces, and that's a feature you won't get with SPF FAIL.  For
"all" read "the obvious bounces" as discussed above, not all
the other backscatter (vacation + C/R + AV-"feedback" + ...)

> SPF adds overhead and expects changes to email practices
> before being fully effective.

No, SPF FAIL works already for those who want it.  It's a pure
voluntary system, nobody is forced to participate.  As far as
changing 1123 5.3.6(a) forwarding is concerned, that's the job
of the receivers:  Check SPF at the first border MTA, and white
list all forwarding MTAs on the receiving side if you check it
"again" later.  How they arrange this isn't the business of the
sender, there are many ways to get it right.  Not limited to
ignoring the issue, if a "251" results in a "pseudo-551" it is
in the spirit of STD 10 and SPF's "back to the routes".  In
that case let the sender figure it out, "551" is no new idea.

> Those who publish SPF records are at risk of being block-
> listed when these records have been exploited. : (

Yes.  If you can't risk PASS don't, use NEUTRAL.  But before a
decent 2476bis 6.1 MSA you can always use PASS.  So far only
two users were seriously interested in some kind of "HARDPASS",
I've noted that as op=auth.  Pointless at the moment, because
it's irrelevant for receivers, it's only relevant in conjuction
with future "reputation systems".  Enjoying the IETF tools see:

http://tools.ietf.org/html?url=http://purl.net/xyzzy/home/test/draft-spf-6-3-options-09.txt#section-3.4

> SPF qualifying the return-path is defunct as there are no
> records defined for this purpose, with this record usurped
> by Sender-ID.  The opt-out strategy still risks wholly unfair
> treatment.

Those unethical activities (we can rule out the mere "error" as
proposed by Keith some months ago at this time) are no flaw in
the SPF design.  I've formally asked the SPF Council to support
an appeal to the IAB:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/19909>

IIRC you also reported your concerns to iesg@ietf.  It's all on
public record, everybody can draw his conclusions, and I won't
participate in any IESG-sponsored opt-out schemes.

            A happy new year to all spam fighters

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Douglas Otis <[email-masked]>
Date: Sun, 1 Jan 2006 19:01:03 -0800

On Dec 31, 2005, at 10:31 PM, Frank Ellermann wrote:
> Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or  
> something else ?  For the former I'm lost, I read the now expired  
> BATV draft, and for SES all I know is that they can optionally use  
> the SPF "exists"-mechanism somehow resulting in 1123 5.3.6(a)  
> compatibility.  I wasn't very interested because IIRC it worked  
> only for domains with their own name server (?)

With authorization misuse, the desire would be to avoid an  
authorization approach.  Finding a syntax compatible with the scheme  
defined in BATV and that of SES was simply to find consensus for the  
syntax to move forward.  The "exists" scheme does not seem to make  
any sense either, but BATV does.

>> BATV does not depend upon any third-party adoption.
>
> returned messages are rejected by BATV.  That's the same issue as  
> for SPF, only more restrictive:  SPF allows to aggregate unrelated  
> sending routes per domain.  BATV works for one and only one MON  
> (all its MSAs plus the corresponding MRN).  And I don't see how a  
> "bounces-to" fan could accept this.

Just as domains are aggregated in SPF records, BATV signatures (with  
mutual arrangements), can be applied to allow a diversity of SMTP  
senders.  Receiving domains can also make exceptions for individuals  
that wish to "opt-out".  Coverage does not need to be 100% to be an  
effective deterrent for DSN or auto-response exploits.   
Alternatively, SPF would need a "per-user" lookup.  Yet SPF still  
allows any miscreant to exploit open-ended records  needed for the  
same reasons someone would want to opt-out, in addition to the alias  
address issues that will not affect BATV.  Depending upon use of call- 
back, a message without a valid BATV tag would be more likely  
delivered with a comparable loss of DSNs to that of SPF with today's  
tactics.  BATV allows a per-user opt-out strategy without any "per- 
user" lookup at the receiving MTA.  The effort is completely  
contained within the domain implementing the BATV strategy.

>> As part of the BATV draft, when the message is delivered, removing  
>> the tag or obfuscating the BATV <glob> section in that is normally  
>> prefixed as "Return-Path:" would also be a helpful practice.
>
> IMHO that would break vacation-like 3834-applications, their auto- 
> responses would be rejected by the originator's BATV-MRN.

Those applications would need to be ahead of the obfuscation or sent  
to the From instead.  The message has been delivered, and having a  
means to reduce the potential for replay would be helpful.

> It's not that I don't like BATV, but it can't substitute SPF FAIL.   
> For those who can do both they should certainly try it.

For those domains in commerce, BATV does not risk as many delivery  
issues, whereas SPF will when delivering to those using their Alma  
Mater email address, for example.  Nevertheless, BATV can effectively  
deter the "side-stepping" exploit which is where spam is really abated.

> You're not talking about creating BATV local parts in the MUA, or  
> are you ?  That would be another FUSSP trap.  IIRC the BATV idea is  
> to replace the local-part of the MAIL FROM at the MSAs (or mail- 
> outs behind an MSA), and undo that modification later for the local  
> part of the RCPT TO at the MXs (or MDA) in the case of "returned"  
> mails, invisible from the sending MUA's POV.

Agreed, BATV would not be implemented at the MUA.

> Sorry, I fail to see how, not without "call-back-verification" at  
> the side of the primary spam victims.  Or an equivalent pre-abuse- 
> address-quality-control-test by the spammer.  The latter strategy  
> worked for SPF FAIL because professional spammers use SA for their  
> QoS-tests (1).  Without knowing SA I doubt that it supports "call- 
> back-verification", that's rather expensive, or isn't it ?

BATV would depend upon a different paradigm.  Rather than receivers  
checking for closed-ended records that _may_ have been published by  
senders to curtail forged return-paths, the forged return-path is  
curtailed without such records being exchanged, simply because the  
receiver implemented BATV.  The overall overhead is less, the effect  
more complete, and the impact upon email practices less.

> Well, the "SPF-opposition" is apparently determined to let SMTP die  
> while preserving 1123-5.3.6(a) "251"-forwarding, and a dead SMTP  
> won't feel the pain.
>
> Most SPF FAIL policies are a "die, spammer, die" voice against 1123  
> 5.3.6(a).  Excluding a few who publish -all without RTFM.

Avoiding the DSN and auto-response exploit curtails abuse, so perhaps  
better defining the problem would help.  SPF records can be published  
by anyone, and there remains many records open to exploitation.

>> Rather than compiling lists of addresses for outbound servers for  
>> a set of domains by issuing dozens of DNS lookups,
>
> NAK, still two lookups in my case before you have either PASS or  
> FAIL.  In theory one query would do, but I won't bother my ISP with  
> this minor improvement before SPF is at least a PS.

SPF requires as many as 111 DNS lookups.  As these are published by  
anyone and with broad distribution, the number of records is  
unknown.  With BATV, the number of DNS lookups is zero.

>> This is a problem only when a third-party attempts to verify the  
>> return-path.
>
> "accept-then-bounce" setup.  That was "state of the art" until 2001  
> as documented in 2821.  Won't make it into any 2821bis.

It would be difficult to imagine a store and forward scheme where an  
exploit does not remain possible.  This expects the recipient to  
fully vet all messages, perhaps even achieving delivery before  
accepting the message.  There are many cases where better strategies  
should be implemented.  There is a cost associated with this vetting  
however, such as holding sessions open.  Being able to ensure forged  
return-paths are not effective when returned would better realize the  
efficiencies of a store and forward system.

>> Prevent the bounce delivery strategy from being successful, and  
>> soon it will not be used.  BATV prevents this strategy from being  
>> successful without changing email practices.
>
> IMO it's in most cases no "delivery strategy".  2821-DDoS and Joe  
> Jobs excluded I think the spammers just abuse any address surviving  
> "call-back-verification".  They really try to reach their primary  
> RCPT TO victims, not the secondary MAIL FROM.

There are those that do better vetting of the remote IP addresses,  
where this delivery strategy side-steps this vetting.

> And BATV does nothing for the existing primary victims, it only  
> blocks most "user not found" + "user over quota" bounces at the MX  
> of the secondary victim.

BATV depends upon the primary vetting of the source identifiers to  
abate abuse.  As a result, BATV can be more effective at preventing  
abuse, but just with a different paradigm.  SPF only changes the  
tactics without long term benefits.  There is also a downside where  
SPF records will be used to unfairly accrue reputations.  At that  
point, email would remain viable for mega-domains or those domains  
that run their own servers.

> BATV has none of the SPF FAIL advantages for primary victims, it  
> only blocks some of the backscatter.

SPF can be published by anyone.  SPF does not afford any real  
protection without the application of reputation.  When SPF  
authorization is used in conjunction with reputation, disaster.

> BATV does nothing wrt obscure C/R systems.  Behind an SPF PASS C/R  
> systems might actually work as expected for the first time.  Behind  
> an SPF PASS the complete SMTP up to 3834 works again.
>
> "all" read "the obvious bounces" as discussed above, not all the  
> other backscatter (vacation + C/R + AV-"feedback" + ...)

The list of where BATV is expected can be modified as needed, when a  
legitimate domain has been exploited.  Those of individuals on  
vacation bouncing with the initial RCPT TO address, then any problem  
will be evident immediately when the auto-responses are refused.   
This would be an indication that this "feature" is being exploited.   
With BATV, this blunder is self healing.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Jan 2006 06:41:58 +0100

Douglas Otis wrote:

> The "exists" scheme does not seem to make any sense either,

AFAIK it's a way to check if mail claiming to be from ses-x@y
was originally sent from x@y - if that's correct nothing is
wrong with the idea so far, domain y only needs a name server
returning 127.0.0.2 for ses-x.y and the "exists"-mechanism.

SPF macros offer %{l} for the local part and similar tricks.
As long as you stay within the limits listed in RFC 3696 you
can do whatever you like.  The SPF spec. mentions potential
traps and pitfalls, 63, 255, 253, other magic numbers.  Stick
to VCHAR plus space minus dot in derived domain labels, %{l}
does not yet come with a "ready for IMA / IEE" icon... :-)

> BATV signatures (with mutual arrangements), can be applied
> to allow a diversity of SMTP senders.

The arrangement could be that user B submits mail at MSA a with
MAIL FROM B@b.  MSA a allows this and implements BATV resulting
in MAIL FROM batv-B@b.  Later the MX of b would accept a bounce
to batv-B@b but not to B@b.  Yes, that could work.

It's beyond me why user B doesn't simply use his MAIL FROM a@A
while sending via MSA a, but that wasn't the question... ;-)

The hardcore "bounces-to" fans would still hate it more than
SPF:  With SPF they wouldn't need much cooperation from MON a
to publish their MON a route in addition to their preferred
MRN b return path.  With BATV MON a would have to play along
and encode b@B -> batv-B@b precisely as expected by MRN b.

The "bounces-to" fans want to be free to use return-paths as
it pleases them, without discussing this with their MON of the
day, or with the MRN hit by the bounces.

> Receiving domains can also make exceptions for individuals
> that wish to "opt-out".  Coverage does not need to be 100%
> to be an effective deterrent for DSN or auto-response
> exploits.

That concept has the nickname "forward-master-plan" in the SPF
community, it's the most simple solution to bypass SPF checks
on a per user base behind traditional 1123 5.3.6(a) forwarding.

> Alternatively, SPF would need a "per-user" lookup.

See above for %{l}.  Not nice for DNS caches, but otherwise it
is possible.  For premium accounts you can also offer per user
policies ("premium" support costs).

> SPF still allows any miscreant to exploit open-ended records

Not really.  You can't get a PASS claiming to send MAIL FROM me
without being a claranet.de customer, and fixing that last hole
is trivial, they could just implement 2476bis 6.1.  Of course a
spammer will find tons of policies where he can get a NEUTRAL
result for forged mails.  But by definition NEUTRAL is the same
as NONE (no policy), and IIRC we used MUSTard for this concept.

> BATV does not risk as many delivery issues, whereas SPF will
> when delivering to those using their Alma Mater email
> address, for example.

That's no argument, nobody needs to use his Alma Mater address
in the reverse path while in reality using an unrelated MSA xy.

If you're allowed to use MSA xy you will also have an address
related to xy, say user@xy, and that could forward all error
messages via Alma Mater to your real mailbox of the day.  The
idea to analyze problems between xy and z by introducing a 3rd
party Alma Mater as "bounces to" is obscure:  More potential
points of failure.  Besides Alma Mater could offer its own MSA,
why use MSA xy if you want replies and bounces at Alma Mater ?

Now folks are free to be as stupid as they wish, and in theory
Alma Mater can support this by just not publishing FAIL.  FAIL
is for those who desperately need it, not for folks celebrating
their first university address for the rest of their live.

> With BATV, the number of DNS lookups is zero.

Yes, and the number of rejected forged MAIL FROMs at the
primary victim based on BATV is also zero, you get what you
pay for, from the primary victim's POV nothing... ;-)

> Being able to ensure forged return-paths are not effective
> when returned would better realize the efficiencies of a
> store and forward system.

Okay, SPF PASS offers only "it won't hit innocent bystanders",
not too shabby for my tastes.  With SPF FAIL you also get "it
never reaches my existing users", together that's as powerful
as it can get before DATA (BDAT / BURL / whatever).

Well, let's agree to disagree, I guess we finished another full
circle, and for the next round we'd need a fresh BATV draft.

                         Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 02 Jan 2006 16:29:31 -0800

> returning 127.0.0.2 for ses-x.y and the "exists"-mechanism.

This requires at least three and perhaps several more DNS lookups to
resolve email-address authorization.  Placing greater burdens on the
recipient with additional external lookups does not make sense. 

> day, or with the MRN hit by the bounces.

A transparent scheme could allow complete freedom by encoding a
translated return-path in the BATV tag, which is de-encapsulated in a
manner illustrated in VERP for a list-server.

http://cr.yp.to/proto/verp.txt

The opt-out list avoids this effort.  Over time, nested tags could
become a common method to deal with this issue.  The exception lists
seemed easier. 

> is trivial, they could just implement 2476bis 6.1.

Are you suggesting the MSA blocks submissions?  How does that prevent a
miscreant?

> Of course a spammer will find tons of policies where he can get a
> NEUTRAL result for forged mails.  But by definition NEUTRAL is the
> same as NONE (no policy), and IIRC we used MUSTard for this concept.

Unfortunately this may also result in those with open-ended records
becoming block-listed. : (

> There will be a

A transition period will last years, if not decades.  Looking for a
simple transition should consider this process.  I agree, opt-out is not
an optimal solution, and perhaps nesting would be preferable.

> pay for, from the primary victim's POV nothing... ;-)

When the recipient can better depend upon source identifiers for vetting
email, then this improves abatement.  In that regard, BATV does indeed
provide the primary victim (the domain implementing BATV) much better
protection.  The expectation that SPF will directly prevent abuse is why
authorization is being abused as authentication.

Anyone can publish SPF records.  Anyone can implement BATV.  Preventing
the success of the exploit will likely alter the behavior of the spammer
as you suggested.  Those implementing BATV will be much less likely
targets, as this clearly indicates which sources are sending forged
return-paths.  Improving upon the source identifier block-list is where
protection is obtained, and BATV helps in that compilation. 

> as it can get before DATA (BDAT / BURL / whatever).

The disagreement seems to be what abates abuse.  No mechanism by itself
abates abuse.  I like the phrase "jumping through hoops" used by John
Levine.  Erecting more hoops will not abate abuse.  An authorization
scheme will not conform to existing practices, nor does it provide a
suitable identifier upon which reputation can be applied.
Unfortunately, as reputation is the active ingredient in abatement, the
unfair misuse of authorization as a source identifier is certainly
inevitable. This is especially true when open-ended lists are needed and
abuse persists.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Jan 2006 13:46:14 -0800

John Leslie wrote:

>Nathaniel Borenstein <[email-masked]> wrote:
>  
>
>>On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote:
>>
>>    
>>
>>>Reputation remains the only solution able to abate the bulk of abuse.
>>>      
>>>
>>... I think most of us pretty much agree about the critical role of
>>reputation.
>>    
>>
>
>   I've noticed a lot of what I call "lip service" about the critical
>role of reputation. To say this differently, many folks seem to think
>you can choose a "reputation system" almost at random, and it's sure
>to improve your signal/noise ratio, "unless you've chosen the wrong one".
>(which, I suppose, is a tautology...)
>
>   But, in my view, we have no basis to choose the "right" one unless
>we have a good understanding of what it measures and a workable idea
>of how to "end run" when it falsely rejects good messages.
>  
>
I completely agree that reputation has a critical role (although
accreditation is important in many situations, as Phill has pointed out,
and should not be ignored).  However, I have come to believe that there
is a great deal of subtlety below the surface of any good reputation system:

- Preventing abusers from "gaming the system" to get good scores
- Preventing attackers from damaging the reputations of others
- Defending the reputation system against legal actions from those who
feel they have been hurt
- Making it all work within the law, considering privacy laws, restraint
of trade, and so forth, considering that the laws governing this vary by
jurisdiction

For this reason, I don't think the operation of reputation systems
themselves should be defined by IETF; different users will have
different needs.  However, standard protocols for communicating with
reputation systems will be needed, and this is a very important area for
IETF to address.  Transaction rates for lookups will be high, and
careful protocol design is needed.  The use of standard protocols in
this area will allow clients to pick a suitable reputation service, and
to change services without changing their infrastructure.  Both
reporting and query protocols will need to be defined.

Much of this applies to accreditation services as well, although there
are some different requirements (negotiating an accreditor to use
between sender and recipient/verifier, for example).

-Jim

---

From: John Leslie <[email-masked]>
Date: Tue, 3 Jan 2006 17:25:46 -0500

> - Preventing abusers from "gaming the system" to get good scores

   This, IMHO, can never be standardized. We can ask for a web page
(subject to change without notice) detailing what is measured, but I
doubt we could even standardize the questions such a web page should
answer.

> - Preventing attackers from damaging the reputations of others

   This is an area which could benefit from standardization, IMHO.
I'm not sure, though, whether consensus is attainable. I think CSV
did a reasonable job here. While I think SPF fails at this, I doubt
we'd ever get the SPF folks to agree.

> - Defending the reputation system against legal actions from those who

   I think we should steer clear of this issue.

>   of trade, and so forth, considering that the laws governing this vary
>   by jurisdiction

   I see no point in trying to standardize for conflicting jurisdictions.

> different needs. 

   I entirely agree.

> However, standard protocols for communicating with reputation systems
> will be needed, and this is a very important area for IETF to address. 

   I would very much like to do so.

> Transaction rates for lookups will be high, and careful protocol design
> is needed.  The use of standard protocols in this area will allow
> clients to pick a suitable reputation service, and to change services
> without changing their infrastructure. 

   Ease of changing reputation services trumps most other considerations,
in the real world.

> Both reporting and query protocols will need to be defined.

   Reporting, IMHO, needs a standardized minimal-set, not a full set.

   Query protocols should see _a_ standard query, which need not
necessarily return all available information.

> between sender and recipient/verifier, for example).

   In CSV, we standardized a way for sender to advertise accreditor(s).
I'm not sure if anything beyond that will be practical.

   The question of standards for reputation and accreditation, IMHO,
deserves IETF work and could deliver great value. But to be clear, I
do not think it belongs in DKIM.

--
John Leslie <[email-masked]>

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Jan 2006 14:40:28 -0800

>do not think it belongs in DKIM.
I strongly agree.  By CCing the ietf-dkim list on my message I didn't
mean to imply that the work belongs there.

-Jim

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 06:59:04 -0500

>>>>> "william(at)elan" == william(at)elan net <[email-masked]> writes:
    william(at)elan> And yes in case you don't know BoF chairs and AD
    william(at)elan> did deny request to present alternatives to DKIM
    william(at)elan> when it was still called MASS BoF.

Russ did state an explicit course of action for those with
alternatives to DKIM.  He asked them to get a specific proposal
together and ask for their own BOF.

I don't know what mail Russ has received, but I know that even though
we have had another IETF meeting since that BOF, no requests were
copied to me for other related BOFs.