Sendmail on Sender-ID

re: Sendmail on Sender-ID

Engefebania — Tue, 29 Sep 2009 23:01:35 GMT

Hello! Repentant klooper for my english jer, buti particular nice re say gJ$)Kd!!!.

Festivus for the Rest of Us

Port 25 — Wed, 13 Dec 2006 21:50:34 GMT

It’s been an interesting nine months on Port 25. For those keeping track, the endeavors of our

re: Sendmail on Sender-ID

davidmeyer — Wed, 13 Dec 2006 16:44:06 GMT

You know, this is almost funny. I think it is a great step in the right direction, and yet there are people who just can't stop bashing Microsoft, no matter what they do.

I say let's stop this MS bashing...let's focus on the technology, because that is what is going to push innovation past where we are now and really make things work for our customers.

re: Sendmail on Sender-ID

fluke — Thu, 07 Dec 2006 01:30:47 GMT

Thanks for responding Michael.

I was hoping you would say that Sender-ID's violation of RFC2822 was an oversight that has been fixed. But I guess fixing the reference to the video is a baby step in the right direction?

I have my own blog where I discuss the status of Port 25. I discuss more about the contradictions between Port 25 and Microsoft in terms of stated goals. It is interesting to compare Port 25's hjanssen and Microsoft's Brian Burke on how supporting of ODF Microsoft is. But most of this information seems to fall outside what Port 25 is really willing to discuss so I don't bother posting it here. Hence, to be able to keep everything I have written about Port 25 available in one place, copies of my posts also appear in my blog. It seems to me this means that I do intend to republish on another site.

This takes me back to the problem I stated before that there is one set of rules for material still under Microsoft control and a different set of rules when forking it outside of that control. So, while the VS SDK contains terms that are destructive to managing a project in a FOSS style, Codeplex gets the operate outside of some of the restrictions of the VS SDK. This allows Port 25 to offer something that on the surface looks like a FOSS style offering, but in reality the "freedom" is just an illusion by implied wavers of the rules as long as the content is not forked.

At the end of the day, Port 25 compromises the policies and methods of yester-year's MSDN much less than it demands a FOSS developer to compromise to be able to contribute. At the same time, the so-called contributions by Port 25 to the FOSS community are eventually reduced in effectiveness or negated by other efforts conducted by Microsoft.

re: Sendmail on Sender-ID

MichaelF — Thu, 30 Nov 2006 19:50:41 GMT

Fluke: Thanks for pointing out the erroneous reference to a video, that was an oversight on our part. It has been fixed to reflect that indeed we did a podcast with Eric, not a video.

I also want to note that you can go ahead and pull quotes from our interviews to help you in your responses as others have in the past. The MS-PL, under which our content is published, does not restrict that sort of action. The restrictions you cite are applicable when someone wants to host or republish our content on another site which is not your intention as I understand it.

Thanks.

-michael

re: Sendmail on Sender-ID

fluke — Thu, 30 Nov 2006 09:06:33 GMT

This was disappointing on several levels. The biggest disappointment is in Eric Allman selling out on the IETF/RFC standards. But I will get back to that issue later.

For Port 25's part, it is disappointing the choice of words to misconstrue what is being discussed or provided. A simple example of this is that when someone uses the word "video" for a web link it is expected you will find on the other side of the link a video file and not just an audio file.

Previously, Port 25 had an article called "Freedom of Port 25 Content." In this case it turns out that "Freedom" is what you can *NOT* do which includes not being able post a derivative or quote part of a podcast interview. So while I would like to quote parts of the Eric Allman interview so I can better directly reply to them, under the lack of freedom detailed in the "Freedom of Port 25 Content," it appears I can not.

And then there is the use of the "interop" and "standards" tags. It is true the Sender-ID and DKIM can be made to coexist. But these do not exist in a vacuum and should not be the only interoperatiblity issue discussed. Microsoft has made it very clear they have no intention of resolving interoperatiblity issues in the current Sender-ID draft. Instead, Microsoft has attempted to use it's ownership of Hotmail and MSN to do an end run around the IETF standards group and encourage use of the flawed draft as it stands[1].

First issue of interoperation that Microsoft has never addressed is the draft's rewording of the SPF draft. Implementing the current Sender-ID draft *requires* that spf1 records be treated in a different form than the SPF draft specifies. Therefore, software compliant with the current Sender-ID draft treat the SPFv1 using SPFv2.0 conventions that the author of the SPF record information did not intend. This methodology of retrofitting changes on other group's protocols is clearly in bad taste.

But even worse is that the current Sender-ID draft fails to honor the requirements of RFC2822. Following the full text of the Sender-ID draft and interoperating with software that enforce the requirements of RFC2822 may not be possible.

As stated before, Microsoft response to these issues was try to use it's position as owner of Hotmail and MSN to push the flaws forward. In doing so, they knowingly attempted to encourage other organizations to violate RFC2822. This type of action against an existing accepted standard is expected of a company that is *anti-standards* and yet the "standards" tag appears to still apply in the minds of Port 25's moderators.

Even worse, OSP changes nothing in being able to address these flaws. If someone chooses to deviate/correct these issues when implementing Sender-ID then the OSP does not provide them any protection. The only way to get the benefits of OSP is to write exactly to Microsoft's stated draft with all it's flaws or face possible legal action. This should be a major concern given that Steve Ballmer seems to be willing to make it clear that legal action will be coming against members of the FOSS community! So, in this case, the OSP becomes another tool to encourage violation of an accepted RFC standard.

So, back to the issue of Eric Allman. I had a lot of experience with Sendmail. My bat book[2] has fallen apart from extensive use. One of the things that interested me the most of Eric Allman was how he promoted compliance with the RFCs. Sendmail was the first MTA I know of that enforced the requirement that a SMTP "HELO" command have an argument. And in return, some users of Sendmail complained. But Eric Allman held his ground that the RFCs existed for a good reason.

Now to hear him discussing "interoperability" using a Sender-ID draft that voilates RFC2822, well... that must mean one of two things. Either E.A. has failed to do his homework regarding Sender-ID or he has sold out on promoting compliance with the RFCs. Regardless of the reason, this was a very disappointing and painful podcast to listen to. I hope that Allman chooses to one day redeem himself and require compliance with RFC2822 as a provision of his continued support.

[1] http://www.silicon.com/research/specialreports/thespamreport/0,39025001,39131378,00.htm

[2] http://www.oreilly.com/catalog/sendmail3/index.html