1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
|
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>LamsonProject: Frequently Asked Questions</title>
<link rel="stylesheet" href="/styles/global.css" type="text/css" charset="utf-8" />
<link rel="stylesheet" href="/css/code.css" type="text/css" charset="utf-8" />
<!--[if IE 7]>
<style type="text/css" media="screen">
div#column_left ul.sidebar_menu li div.color{
display: none;
}
</style>
<![endif]-->
<link href="/prettify.css" type="text/css" rel="stylesheet" />
<script type="text/javascript" src="/prettify.js"></script>
</head>
<body onload="prettyPrint()">
<div id="content_centered">
<div id="header">
<h1><img id="logo" src="/images/lamson.png" alt="Lamson Project(TM) - Pipes and aliases are so 1970." /></h1>
<ul id="header_menu">
<li><a href="/">Home</a></li>
<li><a href="/blog/">News</a></li>
<li><a href="/feed.xml">Feed</a></li>
<li><a href="/download.html">Download</a></li>
<li><a href="/docs/">Documentation</a></li>
<li><a href="/docs/api/">API</a></li>
</ul>
</div>
<div id="main_content">
<h1>Frequently Asked Questions</h1>
<p>If a question is missing you can <a href="mailto:lamson@librelist.com">email the lamson@librelist.com mailing
list</a> about it and I’ll answer.</p>
<h2> What is Lamson?</h2>
<p>Lamson is a pure Python <span class="caps">SMTP</span> server designed to create robust and complex mail
applications in the style of modern web frameworks such as Django. Unlike
traditional <span class="caps">SMTP</span> servers like Postfix or Sendmail, Lamson has all the features
of a web application stack (<span class="caps">ORM</span>, templates, routing, handlers, state machines,
Python) without needing to configure alias files, run newaliases, or juggle
tons of tiny fragile processes. Lamson also plays well with other web
frameworks and Python libraries.</p>
<h2>Where does the name “Lamson” come from?</h2>
<p>“Lamson Tubes” is a colloquial name for Pneumatic Tubes which were used last
century to deliver mail, packages, and hazardous material to the corporate
world. They are still in use today.</p>
<h2>What kind of applications do you envision being built on top of Lamson?</h2>
<p>Why, spam of course (like I could stop that). As well as spam fighters,
greylisters, “campaign management” applications, mail firewalls, mime strippers
(for those Exchange file shares), help desk support applications, games,
mailing lists ('cause everyone loves writing those), and even <span class="caps">SMTP</span> portions of
just about any web site.</p>
<p>A few examples of applications that are actually written using Lamson (with
source included in the <a href="/releases/">source releases</a></p>
<ul>
<li><a href="http://oneshotblog.com/">OneShotBlog</a></li>
<li><a href="http://librelist.com/">Librelist</a></li>
<li><a href="http://myinboxisnota.tv/">MyInboxIsNotA.TV</a></li>
</ul>
<p>With many more to come.</p>
<h2>How do I install lamson on a Debian or CentOS server?</h2>
<p>Debian and CentOS are notorious for being dinosaurs. Both distributions of
Linux suffer from the false rationale that older software is more stable and
secure. The reality is that the stability or security of a piece of software
is not a function of its age, and in many cases the newer versions of software
will typically fix many stability and performance problems. Despite this fact,
these two variants of Linux are notorious for back-porting patches from later
versions to older versions rather than just using the newer version.</p>
<p>In order to help people who need to run a modern piece of software on their
antiquated operating systems, I’ve written an extensive document on <a href="/docs/deploying_lamson.html">how to
Deploy Lamson</a> that tells you how to do it in a way
that should work reliably on most Unix platforms, even if they have an older
version of Python.</p>
<h2>Is there a mailing list?</h2>
<p>Yes, and it’s written in Lamson. You can send an email to <a href="mailto:lamson@librelist.com">lamson@librelist.com</a>
and you’ll be able to join. The code for this mailing list system is also included in the <a href="/releases/">source releases</a>
so you can learn from it.</p>
<h2>Is there an <span class="caps">IRC</span> channel?</h2>
<p>Yes, and it has relatively low traffic. You can join #librelist on irc.freenode.org.</p>
<h2> How do I report a BUG/Feature/Question in Lamson?</h2>
<p>Currently the best place to report a Lamson bug is to the <a href="mailto:lamson@librelist.com">lamson@librelist.com</a>
mailing list. If you don’t want to subscribe to the list to just report a bug, then you can
<a href="/contact.html">contact me</a> directly to report it.</p>
<h2> How do I work on Lamson?</h2>
<p>I currently do all the work on Lamson myself. I don’t want to discourage contributions, but I’ve
found that when a project is small and just getting started it’s best to keep it under the control
of one person.</p>
<p>If you find bugs, then please report them to the <a href="mailto:lamson@librelist.com">lamson@librelist.com</a> mailing
list to <a href="/contact.html">to me directly</a> and I’ll fix them up.</p>
<h2>How do I try out (install) Lamson? </h2>
<p>Best way to do it is to have
<a href="http://peak.telecommunity.com/DevCenter/EasyInstall">easy_install</a> and simply
do:</p>
<pre class="code">
$ sudo easy_install lamson
</pre>
<p>Then you’ll get it installed and can play with it. Refer to the <a href="/docs/getting_started.html">getting
started</a> documentation for more information.</p>
<h2> How can I get the code to Lamson?</h2>
<p>Lamson lives on Launchpad at <a href="https://launchpad.net/lamson">https://launchpad.net/lamson</a> where you can get the code via:</p>
<pre class="code">
bzr branch lp:lamson
</pre>
<p>Bazaar may ask you to login, but it should still give you the source.</p>
<p>Refer to the <a href="/download.html">download instructions</a> for more information.</p>
<h2>What features are planned for the 1.0 release?</h2>
<p>I try to make “1.0” what most other people would consider 80% complete. This
lets people get it and work with it, and then I can refine it for the 2.0
release with 100% of features people actually use.</p>
<p>With this in mind, I’m planning on the 1.0 release to be based on the sample
applications and my own applications and include the smallest set of features.</p>
<p>The most important part of the 1.0 release will be good documentation and bug
free high quality code.</p>
<h2> What are Lamson’s current features?</h2>
<p>Lamson is currently running a handful of sites and is almost ready for a 1.0 release.
It has these high level features:</p>
<ul>
<li>Very good bounce detection and analysis.</li>
<li>Spam blocking.</li>
<li>Get an application going quickly with the “lamson gen” command.</li>
<li>Full set of <a href="/docs/lamson_commands.html">self-documented commands</a> for managing and developing a lamson application.</li>
<li>Lots of <a href="/docs/">documentation</a> with more to come.</li>
<li>Sample applications for you to base your work on.</li>
<li>Handle mail for arbitrary hosts and addresses using simple regex routing.</li>
<li>Process requests including full access to Python’s complete <span class="caps">MIME</span> email libraries.</li>
<li>Absolutely awesome full conversion to Unicode including complete cleaning of incoming mail.</li>
<li>Routing requests in a standard web application framework style based on addresses.</li>
<li>Processing mail messages (requests) in either simple generic handlers, or in more complex and robust state machines.</li>
<li>Use any Python database storage you want.</li>
<li>Use of Jinja2 or Mako templates, with Jinja2 as the default.</li>
<li>Craft and send plain text or <span class="caps">HTML</span> email including attachments, with a great <span class="caps">HTML</span> mail generation <span class="caps">API</span> that even “knits” in CleverCSS.</li>
<li>Unit test helpers for having a conversation, checking spelling, etc.</li>
<li>Defer processing to Maildir queues for offline handling of bigger tasks.</li>
<li>Extensive logging and development tools for debugging your email applications.</li>
<li>Mutt configurations to fake out mutt so that it talks to your server.</li>
<li>100% code coverage in the unit tests.</li>
</ul>
<h2>Isn’t Postfix/Sendmail/Exim Faster?</h2>
<p>That is a tough question to answer actually. If all you need to do is receive
and deliver email then a well established traditional email server like Postfix
or Exim (please don’t use Sendmail) is the way to go. Hands down these servers
are the fastest and the best at this job.</p>
<p>However, if you need to actually do something smart with your email, like
manage many mailing lists or handle support requests, then these servers are
definitely slower. </p>
<p>The reason is they require that you configure them to take messages they’ve
already received and hand them to a separate process like a Perl, Python, or
Ruby script. This separate process then has to parse the message <strong>again</strong>, do
its job without stepping on any other processes that might be running (that
means locks), and then send response messages back to the server for even more
<span class="caps">SMTP</span> parsing.</p>
<p>With the triple and sometimes quadruple <span class="caps">MIME</span> parsing, the heavy weight
processes, the difficult to manage locking, and the additional configuration
headaches, there’s no way traditional mail servers beat Lamson in speed.</p>
<p>Lamson only processes a message once, maybe twice if you defer to a queue.
Once the message is parsed you get full access to Python immediately, without
spawning a separate process. Even if you defer to a queue, the Lamson dequeue
server stays resident and processes the queue without forking. You can even
run many dequeue servers on mulitple machines processing a shared Maildir if
you need the extra processing.</p>
<p>In the end, threads and function calls beats processes and pipes.</p>
<h2> Why not use Sendmail’s Milter?</h2>
<p>Sendmail has a protocol named “Milter” that lets you write a mail processing
server that acts as a sort of “slave” to the sendmail process. This protocol
is supported by at least Postfix as well, maybe other servers.</p>
<p>Feel free to go try Milter. When you’re done trying to figure out the protocol
from the dense C code, configure the m4 macros, find a decent milter protocol
library that doesn’t involve installing sendmail, and debugging the final
setup, then you can come back and have it easy with Lamson.</p>
<h2> Why does Lamson send messages to a relay host?</h2>
<p>Lamson doesn’t have to deliver to a relay host, but it is a smarter more
practical use of the technology. </p>
<p>Lamson is written in Python and does actually run slower than the established
mail servers. In addition, Lamson is hopefully doing something more than just
routing email around to people. It is probably processing messages, crafting
replies, querying databases, hitting <span class="caps">REST</span> interfaces, and all the other things
you’d want to do with a modern application. This takes time and resources and
are probably more valuable operations than just simple delivery.</p>
<p>For this reason, you want to use a dumb workhorse like Postfix to do your
actual delivery, and reserve the smart processing that has value for Lamson.</p>
<h2>What about security?! Shouldn’t Lamson be 20 processes?</h2>
<p>Have you ever asked why other mail servers are a bundle of a billion processes?
Why have one server receiving mail, another routing it, and another handing it
to users?</p>
<p>The answer is back in the 1970’s most mail was delivered to Unix users in their
home directories or similar files that required special access rights to
modify. Also in the 1970’s special ports like 25 for <span class="caps">SMTP</span> required root
access, which in the tiny Internet of the time meant that the server could be
“trusted”. These two realities of the time meant that to receive and deliver
mail at least some part of the system had to run as root. To keep things safe,
modern mail systems reduce the amount of time spent as the root user by
separating their functionality into different processes.</p>
<p>However, if you never have to deliver to a user, and all you ever do is process
mail and talk to other servers like <span class="caps">RDBMS</span>, then why do you need all this
privilege separation? Sites run just fine with systems running as one or two
processes without the complexity of some illogical privilege separation getting
in their way.</p>
<p>To put this into perspective, imagine that you were writing a Django
application and you were required to have a separate process for the <span class="caps">HTTP</span>
layers, the view layer, the model layer, the <span class="caps">HTTP</span> responses, and the <span class="caps">RDBMS</span>
access layers? Each one required a different user, a different configuration
file, and you needed another process just to keep them all sane. All of this
just so that if someone hacks into your <span class="caps">HTTP</span> server as root they supposedly
can’t cause any damage.</p>
<p>Yet, they are on your server as root after all.</p>
<p>In practice, you can run Lamson as a separate root process, and then use
another “dequeue server” to do the real processing, if you feel you need that
security.</p>
<p>But, consider delaying that decision until you absolutely need it, because the
security benefits aren’t worth the development and deployment hassles.</p>
<h2>How come nobody thought of this before?</h2>
<p>I don’t know why, since it did seem kind of simple. There’s at least one other
project written in Perl called <a href="http://smtpd.develooper.com/">qpsmtpd</a> that does
something similar, and there may be more. If you know others feel free to
<a href="/contact.html">contact me</a> and let me know.</p>
<h2>Isn’t [Insert Random Java Mail Server] actually the first mail “framework”?</h2>
<p>I get this quite frequently when I make the claim that Lamson is the first
email framework, and it may be true that there was a framework out there before
Lamson. The internet is a big place, so anything is possible. However, I
looked really hard and I couldn’t find a single <strong>modern</strong> mail framework. All
that existed were servers I could use to build a framework.</p>
<p>You see, around 2003 or 2004 the concept of “framework” changed. Before then
all you needed was a server with an extension <span class="caps">API</span> named so that it rhymed with
“Servlet”. As long as your server provided a way to drop a class into the
processing queue and let a programmer handle the request you could call that a
framework.</p>
<p>The usual end result for these <strong>servers</strong> is that you could use them to build a
framework if you wanted, but what you’d get is affectionately called a
“frankenstack”. You’d grab an <span class="caps">ORM</span> from here, a template system from there,
maybe a workflow engine, write a Maven or Ant script to manage it, and wire it
all together with some lame secret sauce code you think gives you a competitive
edge.</p>
<p>Then along came the modern frameworks like Django and Rails that included
everything you needed in a bundle that you could use right away. They had <span class="caps">ORM</span>,
templating, routing, higher level request processing, email support, <span class="caps">REST</span>
support, and anything else you might need for the 80% of your application you
don’t care about.</p>
<p>Some people prefer less of these defaults, some people more, but nearly
everyone who has to get a project done prefers more than just an extension <span class="caps">API</span>
so they can build their own framework.</p>
<p>Today if you try to claim <a href="http://james.apache.org/">Apache James</a> is a
framework you’d be wrong. I could <strong>build</strong> a framework with it, but I could
just as easily build that same framework with Python, Ruby, sendmail and even
postfix. James and friends are just servers, not frameworks. In fact, my
experience with James and similar Java mail servers is they are much harder to
use than aliases+pipes in Postfix.</p>
<p>I now advocate that if your framework doesn’t at least support data, views, and
high level logic as first class entities then it’s just a server. You don’t
have to use <span class="caps">ORM</span>, any particular templating, or Finite State Machines like
Lamson does. You don’t even have to settle on only one way to do data, views,
and logic.</p>
<p>You <strong>must</strong> at least support data, views, and logic out of the box so your user
doesn’t have to go shopping at “APIs-R-Us” just to use your gear.</p>
</div>
<div id="column_left">
<ul class="sidebar_menu">
<li>
<div class="item">
<div class="color" style="background-color: #ff0000;"> </div>
<a href="/blog/">Latest News</a>
</div>
</li>
<li>
<div class="item">
<div class="color" style="background-color: #ff9900;"> </div>
<a href="/download.html">Download the Gear</a>
</div>
</li>
<li>
<div class="item">
<div class="color" style="background-color: #99cc00;"> </div>
<a href="/docs/getting_started.html">Getting Started</a>
</div>
</li>
<li>
<div class="item">
<div class="color" style="background-color: #3399ff;"> </div>
<a href="/docs/">Documentation</a>
</div>
</li>
<li>
<div class="item">
<div class="color" style="background-color: #ff3399;"> </div>
<a href="/docs/faq.html">Frequently Asked Questions</a>
</div>
</li>
<li>
<div class="item">
<div class="color" style="background-color: #006699;"> </div>
<a href="/about.html">About Lamson</a>
</div>
</li>
<li>
<div class="item">
<div class="color" style="background-color: #0099cc;"> </div>
<a href="/contact.html">Getting Help with Lamson</a>
</div>
</li>
</ul>
<div class="sidebar_item">
<h3>Quick Start</h3>
<p>See the download instructions for information on getting lamson, and read the getting started instructions to start your own application in less than 10 minutes.</p>
</div>
<br/>
<div class="sidebar_item">
<h3>Mailing Lists</h3>
<p>Lamson hosts its own <a href="/lists/">mailing lists</a> as well as provides a free open mailing list
service for anyone who needs one. Simply send an email to the list you want @librelist.com and it will
get you started.</p>
</div>
</div>
<div id="footer">
<div class="footer_content">
Lamson Project(TM) and all material on this site Copyright © 2009 <a href="http://zedshaw.com/" title="Zed Shaw's blog">Zed Shaw</a> unless otherwise stated.<br/>
Website Designed by <a href="http://kenkeiter.com/">Kenneth Keitner</a> and donated to the LamsonProject.
</div>
</div>
<!-- end:centered_content -->
</div>
</body>
</html>
|
