On Sun, 12 Dec 2004, David Woodhouse wrote:
To whom are you referring? You failed to attribute your citation, and
your broken mail software doesn't even include a References: header.
He was referring to me. My original text he quoted text did not come out
right since I typed too quickly and missed few words, I'm correcting it
below and added previously quoted text that it is all "full". My response
is also below.
On Sun, 12 Dec 2004, Hallam-Baker, Phillip wrote:
The objective here is to stop spam.
On Sun, 12 Dec 2004, William Leibzon wrote:
If I told you that you should stop using email, would you
consider it to be a correct way of dealing with the problem?
On Sun, 12 Dec 2004, Hallam-Baker, Phillip wrote:
You are making a ridiculous comparison but you are also making my case.
No matter what you call yourself, you don't have standing to decide
how SPF is used, nor does anyone.
On Sun, 12 Dec 2004, William Leibzon wrote:
Somehow I did not get how you concluded all that based on what I wrote.
Deciding not to do something is after all very different then deciding
to do it in the way that is contradictary to technical standards.
On Sun, 12 Dec 2004, Hallam-Baker, Phillip wrote:
PRA is not contrary to 'the' technical standard.
1. PRA by itself is not contradictory to standards, but SID certainly is.
PRA algorithm for finding email sender by looking at "Resent-Sender:",
"Resent-From:", "Sender:", "From:" is basically what is written in
RFC2822 and so its direct derivative of standard (so I really do not
see how any intellectual property can be claimed on it). But based on
how the use of these headers is described in RFC2822 it would give
->user<-- last responsible for submitting email to MSA, and not any
intermediate system - like forwarder or mail list (which however
happen to add Sender header by long tradition). So basically for any
MSA->MRA->MRA->MDA, the PRA algorithm will only give you MSA address
of the first hop, but RMX/LMAP/SPF system is path-based validation
of last hop and so the use of PRA for such verification is in fact
technically flowed and its recommendation for adding Resent- headers
on every hop is contradictory to the standard use of those headers.
2. Microsoft wants to reuse PRA verification in MUA, this is another
serious technical issue as RMX/LMAP/SPF is verification of ip address
of last hop in email path and MUA is by definition outside of email
path and has no direct knowledge of previous hop. So this is also
contradictory to standards if you look at it in larger picture of
how email systems works.
You were one of the people who did not want a standard and worked
to prevent one being agreed.
I certainly don't feel sorry that I took part in not allowing technically
flowed approach encumbered by patent (with license that could not be used
by FOSS software that make up majority of mail processing systems) and
with heavy special interest backing on to becoming Internet Standard.
That is not the same as saying that I did not want MARID group to produce
a standard - if that were so I would not have participated there. I note
that originally (and up until MARID interim meeting), we were focused on
RFC2821 identities (i.e. Classic SPF and HELO) and I had expectations that
is what would be worked on. The "merger" of CallerID and SPF announced at
interim meeting produced something that I at first could not decide if its
worth working on or not but after looking in detail at the resulting
technical drafts it become clear that was a wrong approach to take. We
should never have gone to 2822 and should have stayed with 2821 and then
we would have produced the standard which very likely would have been
based on SPF.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net