On Fri, Feb 19, 2010 at 01:52, Bob Wyman <[email protected]> wrote: finally a serious answer!
> > SMTP and PSHB implement fundamentally different message routing patterns. > SMTP defines a method of implementing "sender controlled" message routing > while PSHB defines a method of "recipient controlled" message routing. > In a sender-controlled system, whether a message reaches a particular node > in the network is determined exclusively by message routing information > attached to the message by the sender of the message. This implies, of > course, that the sender of the message must know each of the eventual > recipients of each message or at least proxies for those recipients (a > "proxy" in this case would include things like mailing-list inboxes that > then do further sender-controlled distribution of the message.) On the other > hand, in such a sender-controlled system, the potential recipients of > messages have no means of discovering the set of all senders who might send > them messages. is this really true at a deep level? i mean, if need to postback data via http, doesn't the process of dns discovery and network rounding itself *exactly* suffer from all of the above flaws? doesn't running on port 80 accepting a super simple unsigned data format open me up to getting unwanted messages? we all put form verification tokens in our html for this very reason... > Also, recipients have no means of controlling the rate, flow, > or content of messages received. hrm. i understand this somewhat - but this is also true of anyone running a program on any open port, esp 80, as those of us who have tried to lock down gov't web servers know. this seems more relative than absolute but it definitely a possible major distinguisher. > PubSubHubbub (PSHB) as a "PubSub" or publish/subscribe system implements a > recipient-controlled method of message routing. again - i think this is only true if you ignore DNS. this is not trivial - you are probably aware of the security issues surrounding OpenID as a result of depending on the this same system. this may seem academic but i bring it up because it has a little bit of a 'security through obscurity' smell to it - we all know if spammers can, they will... > In such a system, the > publisher only controls whether or not a message is available for routing, > not which endpoints or even if any endpoints actually receive the message. > In a PSHB system, who receives a message is determined exclusively by the > recipients themselves. Publishers of messages have no means to determine who > the recipients are. (Note: This isolation of publishers from subscribers is > one of the key reasons that PubSub systems, in general, are much less > subject to "spam" than sender-controlled systems. this really does seem dubious to me. i think we can be absolutely certain that you need to be able to replace "less subject" to "impossible to be subject to" (or close to) for people not to find a work around just as soon as everyone on the internet is having their news delivered to their readers via RSS. computing is full of stories like this, where protocols only tangentially address these issues and they all are eventually exploited. > If you're looking for protocols that should be considered as alternatives to > PSHB, you'd probably do better to look at NNTP (Network News Transfer > Protocol) rather than SMTP. <snip> fair enough. i hadn't thought of NNTP actually... more food for thought. > A better protocol than NNTP would be XMPP. This is particularly the case if > you were to implement the XEP-0060 Publish Subscribe protocol extension to > XMPP. This would give you a true "push" protocol with subscription > management and everything else you need. However, you would discover that a > simple implementation of XEP-0060 would give you pretty much what you have > with PSHB today. You'd also discover that it was massively harder to get > anyone to support what you had done since XMPP relies on continuous > connections between servers and doesn't layer on top of HTTP they virtually > all other "modern" protocols do. <snip> indeed. i wouldn't wish xmpp integration on anyone. > I have personal experience implementing and using all of the protocols defined > here and frankly, I'm quite happy to see that PSHB has been able to do in a > very short period of time something that many of us in this business have > been trying to get done for a very, very long time. cool. thanks very much spelling out your thoughts like that, it's the best attempt anyone has bothered to make yet. here is where my mind is currently sitting: - the spam thing is a red herring, no actual security is built into the system. without being baked it my belief is that it will immediately become a target for spammers to do the direct delivery component and lack of sender verification methods. i realize it will be much harder to spam, but it's far from impossible. - simplicity is potentially an edge, on paper, over existing systems. but incompleteness of features and the barrage of features being discussed which are re-inventions leave that an open question which only time will answer. thanks again for the detailed answer, really appreciate that! cheers. -- -a -- be kind whenever possible... it is always possible - h.h. the 14th dalai lama
