In <00c301c4e2e1$7ef23ce0$1a48573e(_at_)idimo2> "jpinkerton"
<johnp(_at_)idimo(_dot_)com> writes:
For example, last week Meng gave a presentation to most of the largest
ISPs in Singapore and used the following presentation:
http://spf.pobox.com/slides/20041210-sg/presentation.pdf
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.
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.
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.
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."
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
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.
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.
-wayne