spf-discuss
[Top] [All Lists]

RE: Agenda item: SenderID Position Statement

2004-12-08 11:22:32

On Wed, 8 Dec 2004, Scott Kitterman wrote:

I agree.  It's an abuse of the v=spf1 record and I don't like it a bit, but
MS isn't going to change.

MS can do as it likes to its own users (i.e hotmail, msn) but we have 
responsibility to let others know about it so they dont follow bad example.
We also should inform MS users so they know who is responsible if they
experience serious problems and know that their options would be to contact
Microsoft and complain about incorrect use of SPF records.

I'm personally most concerned about MS adding SenderID check to Outlook
because this is the worst and most incorrect and most failure-prone use
of LMAP techniques and worst use of SPF records and unlike with hotmail
where list of users while like is limited to only those who buy from MS,
with outlook its lot and lot of users who can be affected.
 
- remove SPF record, as it yields false positive rejection of mail I send
 (or a customer sends)
- adapt the SPF record to PRA - *but*, live in the fear that if we are
 at a position that we just reckon with any abuse of the SPF record,
 that another MTA/MUA will abuse it in another way, perhaps even
 incompatible to the intersection of SPF-classic and PRA I have adapted
 to, so I'll have to adapt the record to all those abuses?

Right.  Option 3 is leave your v=spf1 record as it is and also publish

"spf2.0/pra ?all"

Option 3 is forcing everyone to "opt-out", why are we allowing such spammer
tactics? If somebody wants to publish PRA specific record they should go
ahead and do it with syntax and record type as microsoft wants it and SPF
would take no responsibility for supporting such records.
 
If they wanna do sender ID, they can, but they should use their own
records. And the IETF shouldn't make it part of the base infrastructure,
as long as there are silly software patents around it.

Yes.  I agree 100%

+1 
 
If the council is going to take positions, they should be specific about
SPF or a positive assertion of general principle.  For example, saying that
Sender_ID is bad because the license is incompatible with the GPL is true,
but problematic.  It's better to say that the SPF Council
believes that any solution must be implementable by both commercial 
and free software.

Yeah.

I'd merge those, i.e. be more specific and without saying its bad say 
that SenderID  is not compatible with GPL software and SPF Community 
believes that email standards must be such that it can be implemented by 
both commercial and free software). 

But again I'd like to point out that changing current position doc that
already has people signed under it may not be appropriate - it may
not be perfectly diplomatic  but it does pretty much say what SPF 
Community thinks of SID and that is what matters. And I did suggest
suggest that council write separate letter that would be a lot more 
diplomatic and use that when communicating with other organizations
(with reference to our position paper for those who want more info
 and list of problems with see with SID).

And perhaps the Council should state that the records "we" (the
SPF/classic/v1/whatever community) specify should be used according to
exactly these specifications and only these, as otherwise the
functioning can't be guaranteed.

I think that's a very good approach.  That declaims any responsibility for
MS' abuse/reuse of v=spf1 records without spefically poking them in the eye.

Again, I'd like to be more specific and say what constitues incorrect 
approach as taken by PRA - just listing of facts, you know. 

I don't think we should hide the problems that can hit an SPF adopter
who publishes a v=spf1 record according to the SPF specs if the records
are abused for other checks.

Yes.  And to the extent we understand how to avoid these risks, such as
publishing "spf2.0/pra ?all", then we should document that too (at least in
a FAQ). 

No we should not, this is like agreeing with Microsoft plan to use SPF1 
records, we should not do it and support Microsoft plans or their draft.

I don't think that the SPF council should formally adopt a position
that v=spf1 users should opt out of PRA, just that people shouldn't 
blame us if PRA causes problems.

I think SPF Community (with statement confirmed by SPF Council) should
make it clear why other organizations and end-users should not use SID.

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net