Re: Sender-ID != SPF
James Couzens <[email protected]>
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Organization | 6o4.ca |
| Message-ID | <1099225786.7297.108.camel@code3> |
On Fri, 2004-10-29 at 15:46 -0700, Douglas Otis wrote:
> On Fri, 2004-10-29 at 09:44, James Couzens wrote:
>
> > SenderID != SPF. Please don't associate the two.
>
> I agree. How does one establish a mix of divergent approaches? A chain
> of trust is broken when each node checks a different mailbox-domain. It
> is also seems inappropriate to misapply a record intended for a
> different mailbox-domain. Handing multiple accountable identities is
> daunting, especially when a change in convention between administrative
> domains makes spoofing easy. Correlating the mailbox-domain checked and
> then displayed becomes another matter.
>
> Regardless of the mailbox-domain checked, leaving authorization normally
> open-ended overcomes present problematic header conventions. Only
> institutions dealing with a phishing problem would have an incentive to
> tackle closing the authorization list. Changing from an address-list to
> a name-list overcomes exploits invited by an open-ended authorization
> list as well, as this would imply a separate entity is utilized for
> reputation.
>
. o O Mmmmmm... I wonder just how it was possible that something like
the KISS principle was completely cast aside instead opting to do the
exact opposite.
I do not know about you, but if I was put in charge of getting a penguin
and a misappropriated series of window frames in a room to chat about
implementing a technology of which the window frames seem incapable of
intelligently dealing with IPR claims to (and without involving their
Media/FUD machine every time), I would try to keep things as simple as
possible.
There exists a very amusing /. post which had a would be chat involving
client's whose names represented the various parties with vested
interest in the outcome of this WG's efforts. I'm not going to post it
here but its exceptionally amusing, and unfortunately a very accurate
representation of the events that took place here. Hopefully we won't
see a repeat of this in the future.
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBhNq6MagRinp8fc8RAglqAKDesmgBsJVIUEwJ8xWJFQM4DQ205wCg0N6j ER9wtJAaayCm9Ylkb8aZQGk= =Phuq -----END PGP SIGNATURE-----