root/doc/FAQ.txt

= Project Lancelot FAQ =

(or, rather, questions likely to be frequently asked if anybody would
actually use the software except myself)

== Project Lancelot Meta-Information ==

'''Q.''' Where do I get Project Lancelot?

The official Project Lancelot web site is at
http://lancelot.anselms.net/ . This contains the software (both
ready-made releases as well as the master revision control repository,
available through Mercurial), documentation, a timeline, roadmap and
bug-tracking system.

We're working on getting Project Lancelot integrated into the Debian
GNU/Linux distribution but there is no timeframe for this yet.

'''Q.''' Why the funny name?

'''A.''' If you think »Project Lancelot« is funny you must not have
heard of that other mailing list manager which is called »Enemies of
Carlotta« :^)

The name came up when we were talking about starting the project. I
had recently been reading T. H. White's »The Once and Future King« to
my SO, and it occurred to me that mailing list management as a field
of endeavour was in dire need of a knight riding in to slay all the
dragons and free all the damsels in distress. Of course for all the
nobility this is ultimately futile (we're not going to replace Mailman
anytime soon), hence Lancelot. I could have called it Don Quixote but
that name is already spoken for.


== Project Lancelot Configuration ==

'''Q.''' How do I conveniently transfer settings from one list to
another?

'''A.''' You can initialise a new list from the settings of an
existing list using
{{{
  $ pl-init --clone=oldlist@example.com newlist@example.com admin@example.com
}}}
This will use the configuration settings from ''oldlist@example.com''
except for the '''list.name''', '''list.address''', and
'''list.owneraddress''' parameters, which are set as for a new
list. The details are in pl-init(1). It is also possible to override
individual items when cloning a list, by giving them on the command
line as usual.

Once a list has been created, a nifty way of transferring (groups of)
configuration items is by doing
{{{
  $ pl-conf -q oldlist@example.com PATTERN | pl-conf -i newlist@example.com
}}}
where PATTERN is something like ''digest.*'' (to transfer all digest
settings).


== Project Lancelot and MTAs ==

'''Q.''' How do I let users manage their own mailing lists without
involving the mail administrator?

Project Lancelot stores mailing list meta-information in a user's home
directory, and therefore there is no problem with this in
principle. The main problem is actually getting mail for a new mailing
list into pl-incoming(1) without having the mail administrator edit an
aliases file (or similar). How to do this depends on the system's
MTA.

It's probably easiest if you're running Qmail; for a list called,
say ''jdoe-list@example.com'', the user ''jdoe'' simply puts a
''.qmail-list-default'' file into their home directory that redirects
all mail into pl-incoming(1) (some translation of return codes may be
necessary).

With Postfix, the problem is that while one can use a
''recipient_delimiter'' like ''+'' to handle addresses like
''jdoe+list@example.com'' by means of a ''.forward+list'' file in
''jdoe'''s home directory, it is impossible to foresee all adresses of
the form ''jdoe+list-bounce-4711-anselm=anselms.net@example.com''
which might arise through normal mailing list operations and would
have to be handled through their own ''.forward'' files. It is
probably best to use an MDA on steroids like Procmail or Mailfilter to
funnel all messages whose address extensions start with a list name to
the pl-incoming(1) command, e.g. (for Procmail),
{{{
  :0 H : list.lock
  ^TOjdoe+list
  |/usr/bin/pl-incoming list@example.com
}}}
If you're handling mail for many different domains, a more convenient
way may be to use Postfix's ''virtual_mailbox_domains'' together with
an MDA like Mailfilter (Postfix's virtual(8) delivery method is
insufficient because it does not allow delivery to user-specified
programs).

'''Q.''' What is this VERP thing and why would I want to use it?

'''A.''' VERP, or Variable Envelope Return Path, is a method of
finding out which bounce messages came from which subscribing
address. While the subscriber address is often obvious from a bounce
message, this is not always the case -- people move to new addresses
and get their mail forwarded from their old accounts, but do not
bother to change all their mailing list subscription. Hence Project
Lancelot may be sending a message to ''jdoe@example.com'', whose owner
may long since have moved to ''john.doe@elsewhere.net'', getting all his
mail sent on from ''example.com'' to there. If the ''elsewhere.net''
address develops a problem, a bounce will be sent to Project Lancelot
from the ''john.doe@elsewhere.net'' address, which Project Lancelot will
not be able to find in the subscriber database, since the subscription
is still in the name of ''jdoe@example.com''.

VERP works by encoding the original subscriber address into the SMTP
envelope return path, which is the address that a receiving MTA uses
for bounce messages. Instead of putting something like
{{{
  MAIL FROM:<lancelot+bounce@anselms.net>
}}}
in a message for ''jdoe@example.com''
(which would direct all bounces to ''lancelot+bounce@example.com'',
with no obvious sign of which subscriber address caused the bounce),
Project Lancelot uses
{{{
  MAIL FROM:<lancelot+bounce-1234-jdoe=example.com@anselms.net>
}}}
Thus, bounce messages are sent to this address, which Project Lancelot
can pick apart to reconstruct that this bounce was caused by a message
to ''jdoe''. (The ''1234'' is the message number, which for now is duly
recorded when the bounce is processed, but not used further.)

'''Q.''' Isn't VERP terribly expensive?

It depends. If you have lots of subscribers at the same domain (say,
''aol.com''), then without VERP you could send one copy of your
message to that domain's mail server, with instructions to deliver
that copy to all of the subscribers there. With VERP, you have to send
one message per subscriber, which of course seems wasteful. However,
for many of us robustness is preferable to speed, so with the costs of
Internet bandwidth being what they are, being able to trace errors is
often worth the extra traffic.

Project Lancelot supports two different flavours of VERP, according to
the value of the '''smtp.verp''' parameter. The first (called
'''lancelot''') lets Project Lancelot do all the work by itself. This
means that, for a mailing list with N subscribers, it sends N copies
of every message to the local MTA, each with the correct VERP
address. The second (called '''smtp''') makes use of the ''XVERP''
ESMTP extension to let the local MTA do the VERPing. This means that
Project Lancelot sends the message to the local MTA with a bunch of up
to '''smtp.maxrecipients''' subscriber addresses at one go (thus for N
subscribers, only N/('''smtp.maxrecipients'''+1) messages are
submitted locally), and the local MTA passes them on with the correct
VERP-encoded addresses. This is preferable because it puts less load
on the local MTA. If Project Lancelot is set up for '''smtp'''-style
VERP and it finds that the local MTA does not support the ''XVERP''
extension, it falls back to '''lancelot'''-style VERP. Therefore it is
usually safe to set '''smtp.verp = smtp''' even if you do not know for
sure whether your local MTA supports it or not.

'''Q.''' How do I find out whether my MTA supports XVERP?

Read the documentation :^) If you're more of a hands-on type person,
you could try something along the lines of
{{{
  $ telnet localhost smtp              <<< contact the local MTA
  Trying 127.0.0.1...
  Connected to mail.example.com.
  Escape character is '^]'.
  220 mail.example.com ESMTP
  EHLO mail.example.com                <<< introduce yourself
  250-mail.example.com
  ... (a bunch of "250-" lines) ...
  250-XVERP                            <<< this line must be there
  ... (possibly more "250-" lines) ...
  250 8BITMIME                         <<< or whatever
}}}
If the output of your MTA in answer to the '''EHLO''' command does not
contain a line saying '''XVERP''', then your MTA does not support the
extension.

''Note for Postfix users:'' Postfix does support the ''XVERP''
extension but, beginning with Postfix 2.1, it must be specially
enabled. In the Postfix ''main.cf'' file, set the
'''smtpd_authorized_verp_clients''' parameter to include the address
and/or network of the machine running Project Lancelot. In the usual
case of Project Lancelot running on the same machine as your MTA,
something like
{{{
  smtpd_authorized_verp_clients = 127.0.0.1/8
}}}
is fine.