[Dovecot] Dovecot aspects of fighting spam

[Phil Howard]

On Wed, Jun 2, 2010 at 10:20, Tom Hendrikx <tom at 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.