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@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@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-----
participants (2)
-
Andrew Sullivan
-
Steffen Kaiser