Subject: [Asrg] BATV + SPF roadmap

From: "David Nicol" <[email-masked]>
Date: Tue, 5 Sep 2006 10:05:12 -0500

On 9/5/06, Frank Ellermann <[email-masked]> wrote:
> > SPF is too old by now to add features to
>
> No, you can add "modifiers", stuff like batv=what.ever.syntax

Thanks. I remembered about that eventually.

To state what may be obvious,
the shortest path would seem to be for

(1) the BATV community to  agree on and test an SPF modifier
syntax&semantics and

(2) document it as frozen and available for use; possibly issuing
patches to the popular spf resolver modules.

-- 
Although efforts are under way to mitigate the problem, this message
may contain flippancy, hyperbole and/or confusing assertions.  Please
reply directly to [email-masked] for clarification of any points
appearing unclear, vague, cruel, frustrating, threatening, negative,
dilletantish or otherwise unprofessional before taking action based on
misintepretation or misconstruction of such points.

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 5 Sep 2006 08:27:56 -0700 (PDT)

> patches to the popular spf resolver modules.

Like it was mentioned, I would remind that BATV is a modification
of SES which came from SPF community. At some point I did propose
that BATV and SES people work together to create syntax for
extended MAIL FROM address (to include SRS), but there was no
interest (and there is no BATV community to speak of anyway).

SES is really a lot better then BATV as far as its integration with
SPF and otherwise its all the same. So what can be done is for SPF 
community to release protocol specification of SES as part of SPF
set of documents, perhaps then it would get more attention.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Levine <[email-masked]>
Date: 5 Sep 2006 16:38:14 -0000

> Like it was mentioned, I would remind that BATV is a modification of
> SES which came from SPF community.

Actually, it's the other way around.  BATV came first under some other
name that I forget now, SES added a lot of extra junk to it to come up
with what I have always seen as an inferior version of DK.  BATV is
deliberately simple and works unilaterally, without recipient hosts
needing to know anything about it.

The BATV documents point out that if there is a per-domain public key
system like DK or DKIM, it would not be hard to do a version of BATV
with signatures that could be verified remotely, but that is something
to think about after we're done with DKIM.

In the meantime, how about that taxonomy?

R's,
John

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 5 Sep 2006 09:53:37 -0700 (PDT)

On Tue, 5 Sep 2006, John Levine wrote:

> Actually, it's the other way around.

You know I've been around during that time too - you better have very
good evidence before you make statement like above. Because I still
remember when you said you came up with BATV concept few days before
MARID's interim meeting in May 2004 and Wayne immediately told you
(or possibly to Dave Crocker - I think he was the one presenting it
on the meeting) that SPF had the same developed as SES and indeed 
spf-discuss archives how it's been developed a year before and its 
original form was exactly like BATV you introduced (difference in
encoding syntax but I'm sure you'd agree this is not important).
I can point everyone to correct archives of when it all happs and
can even point to your posts on SES's own list.

> BATV came first under some other name that I forget now,

Please provide that name and evidence to back up what you said above.

> SES added a lot of extra junk to it to come up
> with what I have always seen as an inferior version of DK.

That was later version of SES which I tole the authors was bad
direction to take it to.

> BATV is deliberately simple and works unilaterally, without recipient 
> hosts needing to know anything about it.

SES can work just like that too. The only difference is that it
optionally to not only to answer if MAIL FROM is properly encrypted
but also to check on that by remote using dns and that can optionally
be referenced from SPF record. In fact same feature can be bullt on
BATV - the syntax is really not all that important.

> to think about after we're done with DKIM.

You originally wanted to also have public-key based BATV signature using 
DK public keys and I pointed out that size of the data you can put in
MAIL FROM is too small for you to use anything but 384k key which is
not going to be acceptable for security reasons (indeed DKIM minimum is
now 1024k).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 5 Sep 2006 10:29:24 -0700

On Sep 5, 2006, at 9:53 AM, william(at)elan.net wrote:

>>> of SES which came from SPF community.
>>
> You know I've been around during that time too - you better have  
> very good evidence before you make statement like above. Because I  
> still remember when you said you came up with BATV concept few days  
> before MARID's interim meeting in May 2004 and Wayne immediately  
> told you (or possibly to Dave Crocker - I think he was the one  
> presenting it on the meeting) that SPF had the same developed as  
> SES and indeed spf-discuss archives how it's been developed a year  
> before and its original form was exactly like BATV you introduced  
> (difference in encoding syntax but I'm sure you'd agree this is not  
> important).  I can point everyone to correct archives of when it  
> all happs and can even point to your posts on SES's own list.

Apples and oranges are similar in that they are both round  
fruit. : )  There might be a desire to standardize upon a common  
syntax however.  From what I can see, the latest BATV draft should  
not impose undue constraints.

> Please provide that name and evidence to back up what you said above.

In John's defense, I recall a few conversations that prompted John to  
document BATV.  These conversations were in regard to a prior concept.

>> The BATV documents point out that if there is a per-domain public  
>> key system like DK or DKIM, it would not be hard to do a version  
>> of BATV with signatures that could be verified remotely, but that  
>> is something to think about after we're done with DKIM.
>
> You originally wanted to also have public-key based BATV signature  
> using DK public keys and I pointed out that size of the data you  
> can put in MAIL FROM is too small for you to use anything but 384k  
> key which is not going to be acceptable for security reasons  
> (indeed DKIM minimum is now 1024k).

When a domain indicates they sign all messages, then BATV imposes no  
additional constrains.  BATV can also offer a valuable method to sort  
through fake DSNs that are sure to happen with DKIM, as the DKIM  
signature will be expected to be damaged.  There was some  
conversation regarding use of public keys, but that never  
materialized.  Perhaps for the reasons you mention.

-Doug

---

From: John Levine <[email-masked]>
Date: 5 Sep 2006 20:35:30 -0000

>good evidence before you make statement like above.

Sorry, pissing contests are off-topic for this list.

SES and BATV have very different goals.  BATV protects against bounce
forgery blowback.  SES is, as best I understand it, includes a signed
checksum of the message intended to let recipients check that the
message was really sent by the putative sender, and some sort of
callback to keep people from delivering the same message many times.

All that BATV does is to let you check incoming bounces to see if they
were provoked by something you sent.  It's a much smaller goal, but
much more achievable.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Sep 2006 02:48:05 +0200

John Levine wrote:
 
> BATV came first under some other name that I forget now

Maybe one of VERP, SRS, DMP, DRIP. FSV, ...  the name doesn't
matter, and who invented what is mainly a historic question -
unless somebody else claims to have "patented" it.  Unrelated:
http://www.ietf.org/ietf/IPR/rsa-ipr-draft-jennings-sip-hashcash-00.txt

> BATV is deliberately simple and works unilaterally, without
> recipient hosts needing to know anything about it.

Yes, that's not good enough.  Receiving hosts wishing to know
something about it should get what they need to reject forged
Return-Paths.

Ignorant hosts would still create backscatter, and BATV would
still catch most of it, that's no issue.  More interesting, if
receiving hosts can identify it, then spammers would also know
which Return-Paths they better don't forge, like they can know
which Return-Paths are SPF FAIL protected.

And the non-ignorant hosts would know which Return-Paths they
can accept "on probation", where later bounces won't get them
blacklisted as ignorants, like they know it today for SPF PASS.

Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 6 Sep 2006 08:36:58 -0700 (PDT)

> Sorry, pissing contests are off-topic for this list.

I was not getting into one. My point is that all public evidence
clearly indicates that SES predates BATV by about a year. And I
was very surprised that you said you did it based on something
else - that is directly opposite to what you said before. But
if you don't want to tell us what it is, that's fine, I'll live
this topic along if it causes you concerns about "pissing contests".

> SES and BATV have very different goals.BATV protects against bounce

As I'm not SES designer, I can not for sure speak about their goals
when it was being developed. My understanding however is that SES
had the same overall goals of stopping blowback and forgery of
envelope MAIL FROM email data.

Developers at some point decided to extend that to include forgery
(or non-repudiation maybe?) of email as a whole (i.e. DATA) - I don't 
think this was ever fully implemented through. Whoever is using it
(as modification of SRS or directly) are all doing it exactly same
way as you do with BATV as way to verify MAIL FROM.

In basic terms leaving (leaving difference in record syntax and format)
BATV is basically a subset of SES where SES allows to do a lot more
functionality that BATV either does not specify or does not allow.

My interest is still to bring it to see standard format for MAIL FROM
signature-like data (including also VERP and SRS) but I'm not going to 
support BATV format over SES or something else (even though you did add 
second separator symbol making even closer to SES syntax) unless SES 
developers and others agree with it and my guess is some neutral 
yet-unused name will have to be for generalized format.

> were provoked by something you sent.  It's a much smaller goal, but

SES works same way plus allows 3rd party to check if you'd accept the
bounce by making DNS query to special RBL-like server (think of it as
SMTP call-back to verify BATV bounce address is correct; but dns is a
lot simpler effort to do it).

-- 
William Leibzon
Elan Networks
[email-masked]