In <724F9981-0200-11D9-9A6B-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
On Sep 8, 2004, at 5:06 PM, wayne wrote:
Publishing SPF records with PRA information has never been a problem
for me (and I think for most others).
The problem is the PRA can not be implemented in most F/OSS MTAs and
spam filters.
Is this a double standard? You do not wish to be restricted by the
encumbrances of another's license yet you wish to restrict others to
the encumbrances of your software license.
I'm sorry Andy, but for the life of me, I can't figure out where this
line of reasoning comes from. You made similar comments in your last
point of you "on the topic of IPR" post:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03751.html
I was going to reply/rebut this line of reasoning, but I saw that
several people said basically what I was going to say.
Yakov Shafranovich's reply:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03759.html
Paul Iadonisi's reply:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03773.html
I think we have a failure to communicate here. ;-)
Even back in my original "Obstacles between us and the finish line"
post ( http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html )
I said:
: 4) IP licensing: I'm not dogmatic about the GPL or commercial
: licenses, but there are significant MTAs and mail filters that fall
: under both kinds of licenses, and several others to boot. I think
: that any proposal that has incompatible IP licensing needs to be
: dropped.
If there was a patent holder who covered some part of the SenderID
proposal and their patent license required using the GPL, I would be
just as bothered.
The issue isn't what individual implementers choose to license their
code under, the issue is whether we should advance a standard that is
incompatible with a very large percentage of current the email
infrastructure. The patent license on the standard covers everyone.
(For what it is worth, the vast majority of software I have written is
under commercial/proprietary licenses far more restrictive than any
F/OSS licence that I know of.)
The PRA is an 2822 identity, which does not cover the
same problem space as the 2821.MAILFROM. The suggestion of using
2821.MAILFROM to get around the SenderID patent mess is like
suggesting using DES to get around the RSA patent mess. Yeah, they
vaguely cover the same general area, but really, they are quite
different.
Just because an identity appears in the same RFC does not mean it has
any better relationship for sender authentication. Certainly
2821.MAILFROM and 2822.From are more closely correlated than 2822.From
and 2822.Cc.
Yes, true, I'm being far to vague when I say "2822 identities". For
the most part, what people discussed as identities back in April(?)
were the HELO domain, the 2821.MAILFROM, the 2822.From:, and the PTR
identity (MTAmark, SS, etc.). The PRA was presented as protecting
"what users see", e.g., the 2822.From:. It was correctly pointed out
that users generally don't see the 2821.MAILFROM.
I think there are valid reasons to consider all four of those
identities because I think they all address different parts of an
overall forgery problem.
If you could come up with a proposal that has broad consensus that
covers the 2822 identities, I could see letting both that proposal and
the PRA going forward. However, I don't see any such proposal.
The syntax does account for future scopes. However, if we cannot
advance the two scopes the people on this list have said they would be
willing to deploy and instead wait around for the definition of a
third scope then where do we stop, on the tenth defined scope?
Well, I haven't seen many people suggest more than four
identities/scopes. I've seen people advance different proposals for
most of these identities. I think we can reasonably stop at one good
standard for each identity.
That doesn't mean that I think that the 2821.MAILFROM identity is a
good subsitute for the 2822.From: identity, or vice versa.
-wayne