Talk:Exim

message: hmm a statement like "even with a poorer basic design model than" needs some qualification. Is this widely accepted or is this parroting djb's rhetoric?
: It doesn't exactly take a wizard to figure out that separating different functionality into different small programs with carefully separated privileges is a design inherently superior in security and speed to the model where everything is lumped into a single binary. Dunno, maybe I take too many things as common sense... --Shallot 17:13, 26 Feb 2004 (UTC)
replies: text: Well, we probably need a generic page on MTAs to provide such generic explanations. --Shallot 15:11, 27 Feb 2004 (UTC)

text: How is this germane to the argument of a poor basic design model?  One problem is a buffer overrun (fixed years ago but still present in Debian's packages); if that's a poor basic design then it's because Exim is written in C and the same applies to most Unix software. The other problem is an issue with what privileges were assumed to be correct for the Exim run-time user and that problem would apply whether the software were multiple daemons or a monolithic binary. Since those problems have been resolved, it's clearly not a fundamental design flaw.  For example, Postfix had CVE-2008-2936 which is also a root privilege escalation issue and similar to Exim's CVE-2011-0017.  Clearly, the design model is orthogonal to the existence of these kinds of issues.  An assertion that Exim has a poor design needs to be backed by references which are specific to the design, not the existence of holes which also exist in software with a design the proponent believes is superior. Phil P (talk) 19:58, 14 February 2011 (UTC)
thread_title:  "poorer basic design model" 

message: I'm having trouble providing publically available documentation for the usage pattern stuff.  The general distribution is based on the mailing list patterns (which I manage).  The other factor feeding into this is that both Suse and RHEL added Exim into their distributions as a stated requirement from EU based customers, however I hold that info as private mail.  I'll see if I can dump general stats from the ML, otherwise I guess on that unless other people have public backup that section can be dropped. --Nigelm
* Thank you for trying to find sources. Uncle G 17:18, 21 December 2005 (UTC)
thread_title:  Sources 

message: I added the software infobox to this article, however I cannot find a couple pieces of information: the developer (Philip Hazel, or a team?) and whether the logo on exim.org is free to copy.  I would assume there would be no problems in uploading the logo of a GPL project, but such things should have confirmation first... --Ec- 16:05, 22 August 2006 (UTC)
thread_title:  Infobox 

message: The last link (Exim Development - From The Cathedral Towards The Bizarre) doesn't work anymore, and I couldn't find any mirrors. Should it be removed?  —Preceding unsigned comment added by 84.90.130.39 (talk) 23:06, 23 January 2010 (UTC)
replies: text: asking the author of that item; ping me if no follow-up fix Phil P (talk) 22:27, 14 February 2011 (UTC)

text: Still broken, more than 5 years later. So I removed the link, and pinged Phil P on his Talk page as requested. Too bad; it sounds interesting. I would have liked to read it. If someone can find a valid reference, please link it again. StormWillLaugh (talk) 10:44, 25 February 2015 (UTC)

text: Thanks to User:TwoTwoHello for fixing the link using the Internet Archive, plus improving this and other references using WP templates. StormWillLaugh (talk) 15:57, 25 February 2015 (UTC)
thread_title:  References 

message: I have noted that various versions of exim will generate received headers containing such phrases as "with emc1-ok (Exim 4.76)".  I note that "emc1-ok" is not a valid registered protocol listed at http://www.iana.org/assignments/mail-parameters for use with the "with" clause of the trace header.  This can cause interoperability problems. 71.106.211.51 (talk) 03:49, 23 November 2011 (UTC)
replies: text: Exim uses an overrideable "received_header_text" configuration parameter to construct "Received:" headers; the default references "$received_protocol" here.  That value can be overriden by an administrator for a particular insertion, but otherwise defaults to one of: "smtp", "smtps", "esmtp", "esmtps", "esmtpa", "esmtpsa"; the only one of these not in the IANA registry is "smtps", which is SSL-on-connect, to which the IETF has philosophical objections; because this connection mode often *has* to be supported in the real world, for interoperability with clients which only support SSL-on-connect outbound, claims that it hurts interoperability would be laughable.  As to "emc1-ok", that is not in the Exim source, nor in any recommendations I know of, so you're looking at some particular site using it, probably for some kind of spam/virus-filtering integration.  The only "interoperability" issue with Received: header formatting is with scanners trying to assign "worthiness" scores to mail by how well it adheres to RFCs, as a crude proxy for a spam metric.  Folks are certainly able to reject on any basis they choose, but rejecting on "received protocol being unrecognised" ranks somewhere alongside "source IP is from a country we don't like" and is almost certainly far less common.  Yet we don't argue that folks choosing to live in a different country hurts interoperability.  With email, people introduce deliberate interoperability issues for spam-fighting and then complain when they find that other legitimate senders aren't quite conforming to their narrow views.  Claiming that this constitutes an RFC Compliance issue because it is *POSSIBLE* to configure an MTA to generate unexpected header values is ... "unsound". Phil P (talk) 05:15, 23 January 2012 (UTC)
thread_title:  RFC Compliance (or lack thereof) 

message: There was a non-sourced comment in the "Updates" section claiming that the rate of releases of Exim slowed, with lengthy gaps. That gives the false impression that Exim has not been very actively maintained since Phil retired in 2007. (I recently saw a blog post where someone claimed that Exim has been "abandoned". I suspect that resulted from a misunderstanding of that comment in this article.) Looking at the release history, that is clearly not the case. Perhaps the release schedule slowed a tiny bit for about a year during the transition period, but that's all. Currently there are releases every few months, and very brisk commit activity by several developers, as seen in the commit history. So I removed that wording, and just wrote that Exim is actively maintained. StormWillLaugh (talk) 10:30, 25 February 2015 (UTC)
thread_title:  Exim actively maintained