On Wed, Jun 2, 2010 at 10:20, Tom Hendrikx <tom@whyscream.net> wrote:
Did you even try to set this up in your test environment (you have one, don't you?) to explore your own capabilities in finding out the behaviour of this edge case? It sounds trivial to do, but you cannot expect other list members to test this for you.
I wish. The mail server was the test environment before the domains were moved over to it. The move was originally planned for June 30, but got expedited to May 25 due to issues with the mail service provider. I will be moving this again probably around October. Hopefully that hardware will be in a couple months before.
This is a startup environment. It means there isn't a ton of cash up front to have the kind of environment that makes sense. But it is coming in at some pace, now. I may even get a real desktop computer in July.
When you change your attitude a bit more towards this direction, you could even add some valuable input to dovecot by suggesting a man page enhancement describing the behaviour of deliver when hitting an empty string as argument to -m (or at least fill the gap when someone else has the same question and tries google for it). Your latest posts to dovecot (and postfix) mailing lists seem to be only highly speculative and have a lot of lengthy arguing, and not much hands-on.
The attitude here is more about get as much done as possible. The mail server is a fraction of what is going on. I work on it when I can. Other things did get dropped the week or so leading up to the expedited changeover. Now that mail is off the problem provider, I do have more breathing time and can actually do some reading. But even so, I'd much rather spend less time reading only what I need, than spend more time reading stuff that includes what I don't need. The reason for that is because I have so much other stuff to read on other projects. Today was spent diagnosing why time servers were refusing to start, and why the monitoring programs on the RAID file servers were not able to access the network. If those problems weren't happening, I'd have been working on the lighttpd (new stuff to read) web servers.
A small example describing a more pro-active attitude:
<phil> Hi list! I need to put spam in a specific folder and want to use 'deliver -m' for this. However, when I set up deliver like this in postfix <config excerpt omitted>, I get the following results that I did not expect when the argument for '-m' was a null string: <log excerpt omitted>.
<list> Hi phil, could you try <suggestion>?. Also, when you do this <config omitted>, you'll most likely get what you want.
<phil> That works great, thanks guys. I'll add you suggestion to the dovecot wiki for future reference.
But that's not reflective of reality. First, I was not committed to using deliver -m at all. It was ONE option. And there was even more than one way to use it. Now I did misunderstand Sieve at that point, because I was addressing things in a different order. Sieve was on the "back burner" because of issues related to user Sieve scripts. I knew I needed to read more about Sieve to address it. But because I didn't connect the concept that Sieve would address this problem, I didn't expedite considering it.
Remember, the plate is more than just full; it is way overflowing. It is prudent to manage time the best you can. This means avoiding things that don't seem to be urgent. That is not a perfect process, since one might not know about the "perfect solution to everything" that lurks in the bowels of the documentation.
But I do try to phrase my initial questions in terms of what documentation to read, or of basic planning directions.
Planning and reading documentation are too often at odds. It's a hard juggle. The best planning is done by knowing everything. But if you spend all the time to know everything, the deadline is long past by the time the decision can be made. So it's something you have to go back and forth with. Read some. Make some decisions based on that.
From those decisions now you have narrowed the field of what is to be read. That means you now have the advantage of less to read.
And often the details are lacking in the documentation. Ways to fill that in do include testing (now, for example, I'll have to get and set up a whole new testing environment for email ... something I hadn't expected to need to do for a couple more months) ... or, asking.
For example, someone could argue that I should have chosen Exim instead of Postfix, and that if all I had done was read everything about Exim, I'd have know it was "better". Well, I'm not going to pass judgment on that. Since I have never used Exim and knew nothing about it (besides that it is another MTA), and have used Postfix some and know some about it, I save time by choosing Postfix. It might not have been the best choice. But making the choice is likely the best time saver because it omits all that time reading about Exim.
Sometimes some choices are easy, because the elements of the choice are simple. In those cases, complete reading might be done in 5 minutes or less. So from start to full knowledge of the major choices might be under an hour. But I have put in at least 12 hours reading time on just Dovecot and Postfix, and still don't know it all. And for a while I was doing a lot of configuration testing, to see what might work and what might not. Some of that even including my own scripts to construct files (ultimately ended up using passwd-file format, even though I had hoped heading into that I could have used CDB format).
To conclude: I think saw some list posting a while ago that contained an example of postfix master.cf using a shell-like ${some_arg:-default_string} expansion syntax. I'm sorry to see that I cannot find it right now. This syntax, or a 3-line wrapper script around deliver containing it, would solve your issue.
However I still think that you'd be better off checking whether deliver will already handle your issue nicely (albeit in an undocumented way).
Well, I do know this. I could write the shim code to run in front of deliver to inspect the message headers and run deliver with or without the -m option. If do that, it means I can defer the time to read about Sieve, and having something in place sooner, even if it is a temporary, inflexible, non-optimal solution.