Alex van den Bogaerdt wrote on the help list:
> there's one specific entity which takes our carefully
> crafted SPF records and then {ab|re}uses them for their
> own incompatible protocol: SenderID.
From time to time a fresh SenderID bashing is good, and
the three or four folks answering that question on the
help list all checked if it *could* be realted to this
issue.
But it clearly was not, and your idea that SenderID PRA
might do strange things with an X-Sender: header field
was, hm, strange. IMO users confronted with wrong SPF
results are entitled to ask questions on the help list,
and sending them away claiming that it's no SPF problem
if SenderID does strange things can only make sense if
their problem clearly is an effect of SenderID.
But this wasn't the case. Even if it turns out that the
implementation did the less plausible thing, and checked
X-Sender instead of 2822-From, there was a good PRA for
a SenderID PASS, and a good MAIL FROM for an SPF PASS.
The implementation is broken, it got FAIL, based on the
2822-From or maybe the equivalent X-Sender.
> If implementors get it wrong when parsing the various
> headers with all their if-then-else decisions, that's
> indirectly the fault of this other protocol, not ours.
> Why should we provide support?
Because a user wanted to know what if anything is wrong.
He is not the implementor, he has no idea what SenderID
is, from his POV this was an SPF FAIL result he didn't
understand, and he was right, it was in fact wrong.
We've not the faintest idea what caused this bug, after
all the HELO check (pure SPF) was okay, rejecting FAIL
at the border is the best possible (SPF) strategy, only
the FAIL was wrong.
> I strongly believe that anything looking at message
> headers (perhaps with the exception of return-path)
> is SenderID
Please take the ten minutes to read RFC 4407, missing a
Sender header field in a SenderID PRA check would be as
stupid as using a 2822-From instead of the MAIL FROM in
an SPF check. Let alone using any unspecified X-Sender.
> I urge all who do actually implement SenderID to
> mention SenderID in their error messages/bounces, not
> SPF.
The user who asked the question has likely never before
heard of SenderID. Apart from being rude it makes no
sense to send users to "SenderID help" (if that exists)
if their problem is a broken SPF implementation. They
won't know what this controversy is about, they could
conclude that rejecting SPF FAIL is best avoided, and
spread FUD. (I'd do that if a help list X sends me to
the Y competition with my X problem. I'd scream that
X is a useless PITA on as many public places as I can)
> I feel like we are an unpaid helpdesk for MS
Simply ignore messages where you feel that way. We are
interested to tell users that they should not use SPF
records for PRA checks, the place where we can do that
is on SPF HELP. On the imaginary "SenderID help" list
they'd hear a slightly different story in conflict with
RFC 4408.
> something I do not like very much.
If some "SenderID helpdesk" exists you'd like it even
less if they answer questions about SPF, or offer their
version about four erroneous characters in RFC 4406 4.3.
Was that a common problem in the last year on the help
list ? After my system crash a year ago, and after
GMaNe lost its SPF HELP access in November, I'm not up
to date with what are frequent SPF HELP problems.
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
> there's one specific entity which takes our carefully
> crafted SPF records and then {ab|re}uses them for their
> own incompatible protocol: SenderID.
From time to time a fresh SenderID bashing is good, and
the three or four folks answering that question on the
help list all checked if it *could* be realted to this
issue.
But it clearly was not, and your idea that SenderID PRA
might do strange things with an X-Sender: header field
was, hm, strange. IMO users confronted with wrong SPF
results are entitled to ask questions on the help list,
and sending them away claiming that it's no SPF problem
if SenderID does strange things can only make sense if
their problem clearly is an effect of SenderID.
But this wasn't the case. Even if it turns out that the
implementation did the less plausible thing, and checked
X-Sender instead of 2822-From, there was a good PRA for
a SenderID PASS, and a good MAIL FROM for an SPF PASS.
The implementation is broken, it got FAIL, based on the
2822-From or maybe the equivalent X-Sender.
> If implementors get it wrong when parsing the various
> headers with all their if-then-else decisions, that's
> indirectly the fault of this other protocol, not ours.
> Why should we provide support?
Because a user wanted to know what if anything is wrong.
He is not the implementor, he has no idea what SenderID
is, from his POV this was an SPF FAIL result he didn't
understand, and he was right, it was in fact wrong.
We've not the faintest idea what caused this bug, after
all the HELO check (pure SPF) was okay, rejecting FAIL
at the border is the best possible (SPF) strategy, only
the FAIL was wrong.
> I strongly believe that anything looking at message
> headers (perhaps with the exception of return-path)
> is SenderID
Please take the ten minutes to read RFC 4407, missing a
Sender header field in a SenderID PRA check would be as
stupid as using a 2822-From instead of the MAIL FROM in
an SPF check. Let alone using any unspecified X-Sender.
> I urge all who do actually implement SenderID to
> mention SenderID in their error messages/bounces, not
> SPF.
The user who asked the question has likely never before
heard of SenderID. Apart from being rude it makes no
sense to send users to "SenderID help" (if that exists)
if their problem is a broken SPF implementation. They
won't know what this controversy is about, they could
conclude that rejecting SPF FAIL is best avoided, and
spread FUD. (I'd do that if a help list X sends me to
the Y competition with my X problem. I'd scream that
X is a useless PITA on as many public places as I can)
> I feel like we are an unpaid helpdesk for MS
Simply ignore messages where you feel that way. We are
interested to tell users that they should not use SPF
records for PRA checks, the place where we can do that
is on SPF HELP. On the imaginary "SenderID help" list
they'd hear a slightly different story in conflict with
RFC 4408.
> something I do not like very much.
If some "SenderID helpdesk" exists you'd like it even
less if they answer questions about SPF, or offer their
version about four erroneous characters in RFC 4406 4.3.
Was that a common problem in the last year on the help
list ? After my system crash a year ago, and after
GMaNe lost its SPF HELP access in November, I'm not up
to date with what are frequent SPF HELP problems.
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com