dovecot - Apr 2015 - What to read about interactions

Hi,

TL;DR: I am having a hard time synthesizing the information I need out
of the website/wiki documentation, and google isn't turning up what I
need, so I'm looking for advice on what I should read next to
understand the way aliases, dovecot's lmtp, and pigeonhole work
together.  Details below.

I've been using dovecot happily for some years, but in a recent
migration of my mail server I set up something that I think will be
slightly easier to maintain.  I now have a single (in my case
postgres) database backing all user names and so on, with postfix
relying on dovecot auth for user validation and delivery.  I have the
usual anti-spam machinery in there, and have started using the (for me
new) pigeonhole implementation of sieve.  (My old mail system was
built around the earlier dovecot implementation, and while I've
patched it over time it's really pretty creaky.)

On the whole, this all seems very nice, but I'm having a hard time
understanding the details of what interacts with what other bits when.
In particular, my mail system is known by several different names, and
I thought it'd be much handier to have everything land in one real
mailbox, since I could sort the inbound mail into different mailboxes
without a lot of trouble using seive.  This has turned out to be
slightly trickier than I thought it ought to be (procmail is in some
ways easier), and I've come to the conclusion that I don't have a
strong foundation in exactly how this is supposed to work.

Apart from reading the code (which would probably at this point be
hard enough for me so as to make it impossible), are there things I
ought to read to understand this better?  I've read the seive RFCs,
but while that gives me a clue about what ought to happen
protocol-wise, it isn't helping me at all to understand the
interaction among the different subsystems so that I can see clearly
how different parts of the delivery chain are interacting.  I'm sure
there's some crucial bit of, "Everyone knows that," that I've
overlooked, and I thought it would be better to ask for the FM than
just to read randomly until I stumbled on it.

Thanks,

A

-- 
Andrew Sullivan
ajs at crankycanuck.ca

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 5 Apr 2015, Andrew Sullivan wrote:
> I've been using dovecot happily for some years, but in a recent
> migration of my mail server I set up something that I think will be
> slightly easier to maintain.  I now have a single (in my case
> postgres) database backing all user names and so on, with postfix
> relying on dovecot auth for user validation and delivery.  I have the
> usual anti-spam machinery in there, and have started using the (for me
> new) pigeonhole implementation of sieve.  (My old mail system was
> built around the earlier dovecot implementation, and while I've
> patched it over time it's really pretty creaky.)
>
> On the whole, this all seems very nice, but I'm having a hard time
> understanding the details of what interacts with what other bits when.
> In particular, my mail system is known by several different names, and
> I thought it'd be much handier to have everything land in one real
> mailbox, since I could sort the inbound mail into different mailboxes
> without a lot of trouble using seive.  This has turned out to be
> slightly trickier than I thought it ought to be (procmail is in some
> ways easier), and I've come to the conclusion that I don't have a
> strong foundation in exactly how this is supposed to work.
procmail is easier ;-)

Think of "Sieve" taking over procmail.

If you want to know how to write Sieve scripts, check out 
http://wiki2.dovecot.org/Pigeonhole/Sieve/Examples or any other Sieve 
site. If you want to filter by mail domain, you need envelope tests, see 
http://wiki2.dovecot.org/Pigeonhole/Sieve, too.

e.g.

if envelope :is "to" "owner-cipe-l at inka.de" {
   fileinto "lists.cipe";
   stop;
}
> Apart from reading the code (which would probably at this point be
> hard enough for me so as to make it impossible), are there things I
> ought to read to understand this better?  I've read the seive RFCs,
> but while that gives me a clue about what ought to happen
> protocol-wise, it isn't helping me at all to understand the
> interaction among the different subsystems so that I can see clearly
There are no "subsystems", as far as I understand the term. There is 
information about the current message, which can be tested and acted on.
> how different parts of the delivery chain are interacting.  I'm sure
> there's some crucial bit of, "Everyone knows that," that
I've
> overlooked, and I thought it would be better to ask for the FM than
> just to read randomly until I stumbled on it.
- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVSPQAnz1H7kL/d9rAQKwzggAgmpsAzrm0FE3/TVMQVq3tnjqxoFwX6ur
JhO1gb1558bEhv95rwtcmsPcEPP8fqstcMoZv9rKnPjgorAzx+t9/hxNhvzer49U
q2NcRRLBrWKt/GdJK3f06Ifs+tUjuog1kotiyR5E193xf/cvEd98H4EyVR35kak3
3tDHsW7ylhU7bg3N6FU9fu6px8EsVKQFG/H3mClltpgsgsq5AJ1jMM6giZH2BJ9d
IwzpnP8WmvXOpTt6YvJOLySiAjWY+8e0c/LjNt/8dmOL/rdqKGY70RNopOOnGarC
JBh0xxDaKnqv3mwbhFKEVLtr+qhKTGbDjlF1G49CebpNpIsTTIXZIA==0pPx
-----END PGP SIGNATURE-----