Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alessandro Vesely wrote:
> in RFC 4408 I read
>
> The community is invited to observe the success or failure of the
> two approaches during the two years following publication, in order
> that a community consensus can be reached in the future.
>
> Since the publication is apparently April 2006, the above implies there
> is a deadline for April 2008. Is that correct? Should we provide a new
> RFC by that date?
>
> The most obvious amendment is, of course, that the protocol comes out
> of its experimental status :-/

Yes, the IETF asked us to collect real-world experience after the
publication of RFC 4408. I think we should make another attempt at
getting SPFv1 onto the standards track.

However, I don't quite see yet how the conflict with Sender ID's
v=spf1/PRA abuse could be resolved. We can claim that Sender ID and
especially spf2.0 records haven't gained significant deployment in the
past two years, but Microsoft could just claim the opposite and showcase
a host of institutions that have allegedly implemented Sender ID (even if
many of them probably have implemented just SPF and no PRA checking).

As for amendments to RFC 4408, I'm extremely sceptical of changing any
semantics of the spec. Maybe we can clean the document up and apply the
handful of errata[1] that we have collected. Adding receiver-side policy
like you suggest in your other postings isn't something that I would do.

References:
1. http://www.openspf.org/RFC_4408/Errata

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHf2lPwL7PKlBZWjsRAk/yAKDYBsJ/6MHxWFwb0Tg/x0XdBSvPcQCeJiQ8
mdR8pNE4RxoWzbv84/tD59w=
=hwx9
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82135948-1931d9
Powered by Listbox: http://www.listbox.com

Julian Mehnle wrote:
> Alessandro Vesely wrote:
>> in RFC 4408 I read
>
>> The community is invited to observe the success or failure of the
>> two approaches during the two years following publication, in order
>> that a community consensus can be reached in the future.
>
>> Since the publication is apparently April 2006, the above implies there
>> is a deadline for April 2008. Is that correct? Should we provide a new
>> RFC by that date?
>
>> The most obvious amendment is, of course, that the protocol comes out
>> of its experimental status :-/
>
> Yes, the IETF asked us to collect real-world experience after the
> publication of RFC 4408. I think we should make another attempt at
> getting SPFv1 onto the standards track.
>
> However, I don't quite see yet how the conflict with Sender ID's
> v=spf1/PRA abuse could be resolved. We can claim that Sender ID and
> especially spf2.0 records haven't gained significant deployment in the
> past two years, but Microsoft could just claim the opposite and showcase
> a host of institutions that have allegedly implemented Sender ID (even if
> many of them probably have implemented just SPF and no PRA checking).

AFAICS, the IETF already erred two years ago. Of course, they can persist.
Meanwhile, phishing has become an internationalized practice and end users
don't know who to blame. The fact that the IETF isn't able to play its
role shouldn't prevent us from playing ours.

> As for amendments to RFC 4408, I'm extremely sceptical of changing any
> semantics of the spec. Maybe we can clean the document up and apply the
> handful of errata[1] that we have collected. Adding receiver-side policy
> like you suggest in your other postings isn't something that I would do.

I didn't mean to subvert the semantics of the specs. Rather to make them
more directly comprehensible. It is difficult to explain why plain message
forwarding should be considered harmful using a sentence that ends up saying
that "[in some circumstances] the recipient MAY refuse the message". E.g.
http://en.wikipedia.org/wiki/E-mail_forwarding#_note-forward_c_harmful

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82730677-0dea1a
Powered by Listbox: http://www.listbox.com

Julian Mehnle wrote:

> I don't quite see yet how the conflict with Sender ID's
> v=spf1/PRA abuse could be resolved.

We specify a IANA registry of SPF tags + modifiers + options
like this:

Record tag Specification, applicability, (status)
v=spf1 4408
spf2.0/mfrom 4406, same as v=spf1 (DEPRECATED)
spf2.0/mfrom,pra 4406, same as v=spf1 + spf2.0/pra (DEPRECATED)
spf2.0/pra,mfrom 4406, same as spf2.0/mfrom,pra (DEPRECATED)
spf2.0/pra 4406

Modifier Specification, applicability, (status)
redirect= 4408, used for v=spf1 and spf2.0/pra
exp= 4408, used for v=spf1 and spf2.0/pra
op= NNNN, used for v=spf1 and spf2.0/pra

Option Specification, applicability, (status)
op=pra (eliminated by what I'm talking about)
op=auth NNNN, used for v=spf1
op=strict NNNN, if Scott still wants it for SSP ;-)

This proposal will explain why mixing v=spf1 and spf2.0/pra
cannot work in practice: A v=spf1 implementation doesn't
necessarily know what spf2.0/mfrom (etc.) is, and vice versa
an spf2.0/pra implementation won't care about obscure op=pra
drafts.

It will also explain that v=spf1 and spf2.0/pra are rather
different, and that spf2.0/pra support is poor because PRA
inherits all v=spf1 issues adding its own PRA issues while
losing the very desirable v=spf1 PASS advantage.

It will be clear (between the lines) that PRA might turn out
to be hopeless for now, it will be also clear that spf2.0/pra
and v=spf1 are disjunct: "Updates 4408" and "updates 4406".

> As for amendments to RFC 4408, I'm extremely sceptical of
> changing any semantics of the spec. Maybe we can clean the
> document up and apply the handful of errata[1] that we have
> collected.

And elaborate on the "DDoS" SHOULD in some way, e.g. picking
your proposal in the "rebuttal", and/or add a recommendation
to use at most one mx-mechanism per record, and to be very
paranoid about evaluating more mx-mechanisms per record.

Plus a few other details, quoted strings in local part etc.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83007000-5bae18
Powered by Listbox: http://www.listbox.com