SES or BATV (was: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)

Frank Ellermann <nobody@xyzzy.claranet.de> Wed, 14 December 2005 17:52 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emao3-0002Kd-7o; Wed, 14 Dec 2005 12:52:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emao1-0002KG-7g for ietf@megatron.ietf.org; Wed, 14 Dec 2005 12:52:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01390 for <ietf@ietf.org>; Wed, 14 Dec 2005 12:51:46 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmapB-0001QC-Kp for ietf@ietf.org; Wed, 14 Dec 2005 12:54:02 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EmaiT-0001zQ-GM for ietf@ietf.org; Wed, 14 Dec 2005 18:47:01 +0100
Received: from 1cust110.tnt9.hbg2.deu.da.uu.net ([149.225.140.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Wed, 14 Dec 2005 18:47:01 +0100
Received: from nobody by 1cust110.tnt9.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Wed, 14 Dec 2005 18:47:01 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Wed, 14 Dec 2005 18:38:10 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 49
Message-ID: <43A05882.6132@xyzzy.claranet.de>
References: <200512092141.NAA00720@gra.isi.edu> <x4fyp1n5xs.fsf@footbone.schlitt.net> <tslbqznbcem.fsf@cz.mit.edu> <x48xuqksa1.fsf@footbone.schlitt.net> <1134489989.5110.47.camel@bash.adsl-64-142-13-68> <439F0E4C.1493@xyzzy.claranet.de> <x4slswke7k.fsf@footbone.schlitt.net> <F7153948-7108-4DC0-B89E-F8B4A19CCCC1@mail-abuse.org> <Pine.LNX.4.62.0512131325560.6721@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust110.tnt9.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Subject: SES or BATV (was: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

william(at)elan.net wrote:

> in practice SES/BATV cryptographic MAILFROM should not be
> looked at an alternative to RMX/SPF method. In fact they
> both are stronger when combined together, however
> unfortunately the different proponents fail to point this
> fact to the wider audience (plus BATV proponents obviously
> ignore the history of this concept both when advocating it
> and in the written text).

Unfortunate that might be, but you really can't expect me to
talk about something that doesn't exist as an I-D (like SES),
or where I came to the conclusion that it doesn't work from
my POV as end-user (like BATV).

Anybody experimenting with combinations will be "delighted" to
learn that (s)he's now expected to "opt out" from PRA first.

Personally I'm more interested in the RMX side of pure SPF, is
RMX "based on dubious premises" as Keith said here recently ?
<http://permalink.gmane.org/gmane.mail.spam.spf.discuss/19922>

If that would boil down to "I don't like it" his conclusion
"no rough consensus" would fail:  There are tons of RfCs like
3865 where personal tastes don't enter the picture.

If that boils down to "1123 5.3.6(a) is no bug" I'd disagree
vehemently.  Besides SPF doesn't force anybody to participate,
there are even ways to participate on the PASS side and still
stay away from the FAIL-side.

Maybe a PASS is already good enough to implement say RfC 3834.
I doubt that he could find a serious bug in SPF.  The trouble
is that he (and some other experts) had no reason to try hard
so far without "last call".

That "last call" business is quite fascinating, everywhere:

It will also affect DKIM SSP, will they get away below PRA, or
could they as well copy your appeal and give up ?  What about
a 2476ter (8.1 in 2476bis doesn't mention Resent-*) ?  What's
the idea of the MUST in 2822 and your appeal, is this a bug ?

Or almost completely unrelated, hell freezes before CRAM-MD5
and ESMTPA die only because Sam doesn't like it, he's forced
to prove his point(s) in a "last call" for "2195bis historic".

                            Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf