9 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] mailfilter does not r...
FromSent OnAttachments
Flemming BjerkeNov 27, 2006 2:52 pm 
Sam VarshavchikNov 27, 2006 3:37 pm 
Tony EarnshawNov 27, 2006 11:37 pm 
Flemming BjerkeNov 29, 2006 7:52 am 
Tony EarnshawNov 29, 2006 2:59 pm 
Flemming BjerkeDec 6, 2006 6:24 am 
Sam VarshavchikDec 6, 2006 3:29 pm 
Flemming BjerkeDec 6, 2006 10:27 pm 
Sam VarshavchikDec 7, 2006 4:10 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [maildropl] mailfilter does not reactActions...
From:Flemming Bjerke (fl@bjerke.dk)
Date:Nov 29, 2006 7:52:28 am
List:net.sourceforge.lists.courier-maildrop

To Sam and Tony, thank you for your replies. Of course, you are right that I don't know enough about maildrop.

But, well, I feel that the documentation is like many other man pages: The basic things are mentioned on equal footing with the refined details, and much information is just taken for granted. This is fine for the experienced user, but for the newbie it is confusing information overload and "under"load at the same time. It is not that I haven't tried reading documentation etc.

My basic question is: How do I get maildrop to read certain mailfilter files?

And I am not the only one who have had that problem: http://forums.bsdnexus.com/viewtopic.php?pid=3385

I must admit I haven't found any answers to that question ...

Tuesday 28 November 2006 00:37 skrev Sam Varshavchik: ....

But, maildrop does not respond in any respect to mailfilter files. In /var/courier/maildroprc, I setup

MAILFILTERDIR="/var/mail/mailfilter"

But, maildrop does react to files in the directory.

Why gave you the idea that it would "react", in the first place?

I thought that maybe I forgot something, at my ripe old age, so just for kicks I searched maildrop's entire tarball for any mention of a variable called "MAILFILTERDIR". I found nothing.

Well, this explains a bit: It is often difficult to google for information about things that does not exist (except ghosts, ufos, etc). Incidentally, this remark helped me quite a lot because it removed some confusion.

Having read the docs again, I have changed MAILFILTERDIR to MAILFILTER, but without any effect. In this connection, I could give you an example of how the documentation may be difficult to interpret for a newbie:

http://www.courier-mta.org/maildrop/?maildropfilter.html

"MAILFILTER This is the name of the original filter file that was given to maildrop on the command line. This is mostly usefull to -default filter files, it allows them to obtain the value of the -M option specified on the command line. "

What does this mean? It sounds a bit odd to speak about an 'original file' given on the command line. And why is this mostly useful to -default filter files??? If it is an original file, it suggests that other files could be used as filter. But, how? Can the variable have other values that the 'original' value? How?

It does not become more clear when I read about these variables:

"The following variables are automatically defined by maildrop. The default values for the following variables may be changed by the system administrator. For security reasons, the values of the following variables are always reset to their default values, and are never imported from the environment."

What is their default values?

And synopsis says: "/etc/maildroprc, $HOME/.mailfilter, $HOME/.mailfilters/*, and friends...". And friends ... what does that mean? .. It is definitely not clear!

So, yes you are right, I should have started from scratch. BUT, if the documentation had been clear, I don't think I ever would have asked the question on this list. Incidentally, you can't do all things from scratch! (Else you should start life from scratch - many times.)

Eventually, I fixed my now-and-here-problem in maildroprc. But, again, the documentation of the mailfilter syntax is not for newbies. On the other hand, courier is free software, and documentation depends on whether anyone has the time for writing better documentation. Often those who really know the programs, prefer to write better code. Therefore, newbies should accept documentation which could be much better, and experienced users should accept confused newbies.

Flemming