Ian Eiloart wrote: > > > --On 7 October 2008 19:49:44 +0800 W B Hacker <[EMAIL PROTECTED]> wrote: > >> >> Am I the Lone Ranger in wanting to tilt toward an implementation ten >> years in use vs one not yet even dry? > > NOPE. There are three suggestions so far: XEXDATA, XLMTP, and XPRDR > > I favour XPRDR technically (strict timeouts enable tarpitting without > losing compliant hosts, for example),
Not sure that cannot be done 'easily enough' anyway... and w/o overly relying on timeouts. > but XEXDATA has the advantage of > having an existing implementation. The biggest advantage is that the Exim community has to do only half the work - eg meet the same documented spec that courier already supports. Finding a few courier-mta users who will test should be easy enough. They'd like to get more use out of their feature as well. Now - XPRDR would at first glance have the same advantage, and source code is there for both of 'em. But I just don't see that XPDR's 'parent' MTA has anything close to the coverage or pool of admins of courier-mta which is in ports and packages everywhere, and in very long-term production use, regardless of 'market share'. Once there are two players interoperable, the third one is easier to enlist. Final and most enduring solution? There ain't no such animal. > XLMTP has the advantage that LMTP is > in widespread use, so there's lots of code out there. > ACK. - but no fewer than TWO MTA have to have an implementation created, of the parts to be used in smtp. We can't just adopt lmtp directly as a substitute. AND they have to be independently debugged AND must interoperate. The fact that it hasn't happened yet indicates it will not be easy to make happen now. > I agree with you that we should favour XEXDATA because it's already out > there, even though I think it is inelegant. > Elegant or otherwise, XEXDATA is reputed to do what it was designed to do in courier-courier interaction, and not just since last year, either. > However, I'd also advocate supporting both EXDATA and XPRDR, because > that might give us code that's flexible enough to be adapted to any > similar scheme. > Can't fault that *so long as* it doesn't kill the whole deal. As all the top F/OSS MTA are 'C' critters, it is all academic until a 'C' coder or three start chunking. Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
