spf-discuss
[Top] [All Lists]

Re: Re: spf-statement-on-SenderID

2004-12-15 14:13:58

----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>

On slides 48-50, SenderID is presented as a merger and heir of SPF and
CallerID.

You'll need to take that up with Meng then - won't you??????

I did.  See:
http://www.schlitt.net/spf/spf-council/2004/12/12_irc_log.html#12-11_21:34

Now, you are complaining that I did raise this issue and you want
to accept neither the SPF community statement (as per openspf.org) nor
the SPF council to in any way say this is wrong.

Not so - I'd be delighted if the SPF council took a firm stance against
misinformation regarding SPF, but I still don't think we should be
commenting on other technologies failings.


Sorry, but I think it is wrong and I intend to bring it to a vote so
that in the future we can point to the vote and disavow any claims by
Meng or Harry or anyone else that SPF is part of SenderID.

Excellent news :-)   I hope you are successful and Meng is big-hearted
enough to accept that resolution.




No.  Confusion only exists because people are actively promoting that
confusion and the SPF community has done almost nothing to stop it.

Well it's time the SPF council did something about that - starting with
fixing Meng's stance.

*sigh*

That is what we are trying to do.

Good, good.  I know it's a hard slog, but I believe it's an imperative.





                           I am not about to tell domain owners what
they should or should not do - there are millions of loyal MS users
out
there and they might want to use Sender-ID.

Wait.  You *are* telling domain owners what to do.  You are telling
them they have to opt-out.  Why shouldn't you tell the "loyal MS
users" that, because the SenderID spec requires you to opt-out, that
the spec knowingly creates problems for them?

Not true - there is *no* injunction to "do" something - the wording was
chosen to avoid that.
" We encourage all existing SPF (v=spf1) record publishers to note this
situation and take appropriate action, depending on whether they are
expecting their outgoing mail to be checked by receivers using Sender-ID
or
not. "

That's not telling anyone what to do other than to be aware of the
situation.

You are telling people to note this and take appropriate action.

Instead of advocating that people have to opt-out, you could say:

"We encourage all people who use SenderID to note this situation and
take appropriate actions, depending on whether they are expecting
their incoming mail to encounter valid SPF records where the PRA fails
to give the correct answer."

Semantics - I don't believe there's a difference noticable by the average
sysadmin ;-)

How about this --
"We encourage all people who use SenderID to note this situation and take
appropriate action, depending on whether they are expecting their incoming
mail to be checked using spfv=1 records where the PRA fails to give the
correct answer."

?






a.  because I have never seen a detailed study of what goes wrong and
when
and why.

Well, then you haven't been reading this mailing list very closely
then.

Quote the mail(s) that gives the full reasons of why and when PRA
doesn't
work when checking spfv=1 ????   There's been a lot of rhetoric, but
little
hard fact.

*sigh*

If it wasn't for the fact that you publish a well know website that
claims to have accurate information about SPF, I would tell you to go
do your own research.  But, just to help you out, here is one such
email:

http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200410/1053.html

But that's a mish-mash of SPF, SES and Sender-ID being used and causing a
problem - hardly a clear example of Sender-ID's use of spfv=1 records
causing a specific problem.

I honestly have not seen a single posting which explains the exact breakage
which Sender-ID will inflict on a spfv=1 record, unless there's some other
factor included.



If you want a complete list of what goes wrong, when and why when
using SenderID, I suggest you review the SenderID statement on
OpenSPF.org, note all the keywords and research the archives of this
mailing list.  I know they are all documented in posts.

There is only one vague reference to the supposed problem of Sender-ID
causing problems when using spfv=1 records - viz:

"SenderID re-purposes the v=spf1 records.  This will cause failures in cases
where deployed SPF records currently work.  In some cases, those failures
can be fixed by changing records, in others (e.g. SES exists:), they can't.
Where SenderID breaks the function of existing v=spf1 records, domain owners
will only learn of it when legitimate mail is not delivered.  SPF record
publishers made their records public with the expectation that they would be
used with the SPF algorithm.  SenderID puts those records to a different,
possibly incompatible use, without any consent from the publishers. "

I don't see any reference to a specific problem here - just a lot of waffle
which is of no use whatsoever to a sysadmin trying to see what the *real*
problem is.




The verbatim forwarding and greeting card issues have had known
solutions since the oldest SPF spec that I have found (June 2003).
Better solutions have been proposed since then, including using an
exists:%{l}._spf.%{d} mechanism to help SES/SRS forwarding, using
receiver whitelists, rate-limiting exceptions, etc.

There appears to be a little self-contradiction here.  You suggest that
I
don't have to comment on other technologies because they aren't
associated
with SPF and don't use SPF records, but you want me to comment on the
"add-on's" that have to be used to fix the various issues faced by
last-hop
authentication.

SRS was once specified in the SPF spec.  It has been broken out, but
it is still closely related.  SES is closer to an unrelated system and
if SES broke the function of classic SPF when it uses the exist
mechanism, I would recommed you comment on it.  However, I know of
nothing in SES that breaks SPF.

Unless you consider the case of the SPF record "v=spf1
exists:%{l}._ses.%{d} -all" - in which case Sender-ID might blame SES for
the breakage ;-)


Don't mis-understand me Wayne - I fully support SPF, but I am trying to
publish a helpful SPF-help website with accurate and incisive information
that allows a sysadmin to make an informed decision about his spf record.
That means it has to include only hard, quoteable facts about the
technology - no opinions, rhetoric, licence issues, slating the opposition,
etc.


Slainte,

JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492