create new tag
, view all tags
Aside: Boy, sourceforge scares me on days like this -- I haven't accessed as many pages as I often do, but I'm getting a ton of "Internal Server Errors" -- makes me worry about creating pages here. Also, donn't know whether I should report it or wait for it to (hopefully) pass. Update: Same problems today -- had to try three times to get this page up for editing.

From EmailInterimStatus you will see that I think I've made quite a bit of progress on getting my email server to work. I'm getting down to the short strokes, I hope. But, I've been fooling around with procmail (making progress here, too) but learned too much which means I need to record my learnings and write down my plan of attack.

Much of my learning is incorporated in the .mailprocrc and rc.testing files on my System8 -- at some point I will condense those files and attach them to this page.

See AboutThesePages.




  • procmail can put mail in any (mail compatible?) file on a system, using for example, paths like /var/spool/mail/ruth, as long as the user (owner) of the procmail process has write permission in that file. (On my system, I set that permission and then found it reset a little while later -- my bet is that msec must exist in Mandrake 7.2 (or the MandrakeFreq Update for it).

The New Plan

  • Pick one user to run the "main instance" of procmail. (Currently intend that to be dad -- I thought some about making it root, but it just doesn't "smell" safe.) That user should also be the user that runs fetchmail (whether manually or from a cron job). Thus, mail is processed by his procmail first, and some mail is dumped directly into destination mail files for other users.

  • Create a new user named "sent-mail" for the purpose of collecting mail sent from any email client on my LAN, whether using IMAP/SMTP or POP3/SMTP.

  • "sent-mail" will get a bcc of every email processed by postfix via the "allways_bcc" parameter in the postfix main.cf file -- it will then (via procmail):
    • ignore (/dev/null) all mail except mail sent from rhkramer@fastPLEASENOSPAM.net -- that clearly will be the sent mail (for my setup) -- note that this is an unusual setup in that (currently) my family shares one email address. One method of distinguishing the actual sender is by the prefixed name, like "Randy Kramer <rhkramer@fast.net>", or "Ruth Kramer <rhkramer@fast.net>"
  • Further process this mail to eliminate duplicates, as there will be duplicates -- I think -- oops, no -- maybe not -- if a mail is only an outgoing mail (the normal situation), I think there will only be a copy of the outgoing mail -- if it is sent "to myself" as a test, it will be a duplicate, but this should be a small number
  • Further process this mail to distinguish who sent it, and then put it in "sent" folders by person (or "to" folders, depending on the approach desired)

  • All "ordinary" users (ruth, dad, alex) will need to have a .procmailrc and associated files (rc.testing) to sort their mail into folders as desired. dad's files will be the most complicated as it will put incoming mail destined for others into appropriate files in their mail directories.

  • Oops, I want to reconsider which user should be the "first receiver" of incoming mail -- dad (original plan), root, sent-mail-user, some other user, some other user with su (sudo privileges) or should I possibly give procmail for dad suid privileges (as root) (if I understand that correctly):
    • dad -- would need root privileges to put mail in others folders, or would have to be the group owner (or a member of the group owner) of other folders. sent-mail-user would ideally be a member of the same group. So I make dad and sent-mail-user members of mailgroup, and make mailgroup the group owner of the mail folders (and "inbox" -- /var/spool/mail/<username>) of all the users.
      • Hmm, wait -- sent-mail-user may only have to put mail in dad which means it can be the sole group owner of dad's files, and dad can be the sole group owner of the other user's mail files, which may make dad's mail more secure
      • Other users may not like dad being the group owner of their mail folders -- might be better to choose a "neutral" other user (similar to sent-mail-user -- maybe mail-dist-user??) -- slight problem is I have to redo the procmail files and so forth I've already done for dad -- advantage is that it is more scalable on a socio-political basis. Oops, think some more -- since one user (mail-dist-user) will handle main incoming mail, and another user (sent-mail-user) will handle detecting and distributing sent mail, and both will need access to users mail folders, I still need a group like mailgroup to be the group owner of those mailboxes.
    • root -- sounds scary -- many implications covered by the discussion above but I still need a separate entity to do the sent mail detection so I need another group owner of users mail boxes. But wait -- why do I need a separate user to collect sent mail -- was that only to avoid the possible return of sent mail to other users when they weren't expecting it (i.e., they'd have two copies if they kept their own copy on a local pop client -- need to think some more. Still having root receive and distribute the mail just smells like trouble. The two user / mailgroup idea sounds more secure.
    • sent-mail-user -- the following is really more (or as) relevant to some of the ideas above. What was the original problem -- it was this -- a user would be surprised if they got a cc of something they sent if they didn't ask for it, but also surprised if they didn't get a cc of something they sent if they did ask for it. How would procmail know whether they asked for it or not? I guess one way (to be tested and rethought) is if they asked for a cc or bcc (or to) then they asked for a copy, otherwise not. If that is correct, then I think one user can handle both tasks -- oops, wait -- I almost forgot -- I need a way to make the copies of mails that aren't otherwise copied. In some earlier trials I created a mail loop -- either I must avoid that, or fix it. (I think the mail loop came when I used always_bcc to dad (i.e., the same user distributing the mail) -- maybe I can create the necessary duplicates with procmail and avoid the problem. Ok, I'm quite sure I can do that -- outlined with pencil and paper -- basically just distinguish between mails that are From (Randy, Ruth, Alex) rhkramer and one or more of To, cc, bcc rhkramer. Oops, can I see a bcc header somewhere -- need to test. Oops, not so sure -- the previous distinguishes whether the user asked for a cc or not, but may still leave the mail loop -- ahh, maybe not if put directly into a folder rather than remailed with "!" (which I prefer anyway) -- need some testing.
    • some other user -- i.e., mail-dist-user -- already touched on above
    • any of the above with sudo (or UID=0 or 1 (whatever root is) -- sudo is for a limited time, and gives root privileges -- if I repeat fetchmail with a cron job, I essentially repeat the sudo every ten minutes -- before you know it, the user will be sudo all the time.
    • any of the above with procmail suid -- this is the most intriguing, partly because I don't fully understand the possibility -- I guess the first thing is that I have to find the owner of the procmail executable -- is it root, procmail (??). Ahh, but the problem is, if I make it suid, any user that uses it gets the suid privilege (it's a property of the file, not the user, IIUC) -- that might give all users more privileges than I want.

Some incidental points to make the above work:

  • Create a new user group named "mail-group" (assuming it's not already used).

  • Put all local users in the mail-group, give the mail-group write (and read??) permission for all mail files like /var/spool/mail/ruth and /home/mail/ruth. (Oops -- make sure that doesn't let anybody in the group read ruth's mail -- think about this some more -- maybe the mail group should only contain the local user who runs the "main" instance of procmail.

Ok, saving this for now -- time for some testing, etc. Probably first look for a bcc header, then confirm that putting a copy in a user's mail folder does not create a mail loop. Still thinking about keeping dad as the mail distributor as that requires the least amount of rework at this time, but, if I'd want to copy this solution elsewhere in the future, maybe I should do the rework.


  • No bcc header exists in outgoing mail, so that can't be used to detect a bcc. But people don't send bccs to themselves that often -- maybe "incidental" copies of bccs to themselves is tolerable and explicable.

<Currently, no significant content below this line.>


See ResourceRecommendations. Feel free to add additional resources to these lists, but please follow the guidelines on ResourceRecommendations including ResourceRecommendations#Guidelines_for_Rating_Resources.


  • (rhk) [[][]] --

Recommended for Specific Needs

  • (rhk) [[][]] --

Recommended by Others

  • (rhk) [[][]] --

No Recommendation

  • (rhk) [[][]] --

Not Recommended

  • (rhk) [[][]] --


  • () RandyKramer - 19 Aug 2002
  • <If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.>

[[Main.RandyKramer#19 Aug 2002][]]

Rants (Ignore)

See MyRantings.

Not quite a rant, and this will not be exactly what I was thinking a day or so ago, but there is some evidence here of the things that make programming difficult:

  • poor understanding of the real (actual) capabilities of a program (postfix, procmail) that can be gained by reading -- often requires experience and testing to really understand those (likewise for concepts like group ownership and so forth -- easy to get confused)
  • the experience and testing can be painful as there are often too many variables to easily deal with -- you set up a test -- think you've got an understanding, and then find that you forgot to change (or not change) one variable so your results are invalid. I still (at the time I write this) don't understand why I could set up the user sent-mail-user and group mailgroup, make mailgroup the group owner of dad's and sent-mail-user's files (and directories containing the files up the line), set or confirm that those files had rw permission for the group owner (and, directories up the line, rwx) yet sent-mail-user could access dad's files, but dad could not access sent-mail-users files. Why? Oops wait, is there a chance it was because all of sent-mail-user's files are hidden? No, because ls -al will view hidden files.
  • reiterating part of above, too many variables make testing difficult. We (I) need good "testing frameworks" -- not sure what I mean by that, but some magical thing that lets me say I want to test this under controlled conditions -- tell me what controlled conditions I need to consider, control them for me, record the results of several different trials and present it in an easy to understand fashion with a minimum of extraneous variables, and preserve the test framework so tests can be repeated or additional tests added in the future.
  • The same too many variables make documentation difficult. Pedants (people who try to use words with very precise meanings expecting the reader to get a very precise understanding) contribute to the problem because english is just not that precise a language -- words that might have a precise meaning in one context may have a very different and sometimes opposite meaning in another context. (Was Larry Wall just joking when he chose interpolate, or was his background so different than any other programmer, or was he trying to make the same point I'm making by "creating" a joke? (That's a little unfair, so are many things -- maybe when I come back to it I'll phrase it better.) I need to recheck the meaning of "whole cloth" -- I looked it up once -- IIRC, two contradictory meanings exist -- yes they do -- see http://alt-english-usage.org/excerpts/fxwholec.html -- my reading of old books (as a child) and the British still using the opposite meaning provide at least some minimal excuse for me having the opposite interpretation of those in the US legal profession.

Page Ratings

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2002-08-20 - RandyKramer
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look