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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]