Need advice on how to change my current dspam setup to dspam-milter way. about dspam-milter HOT 8 CLOSED

Hi,

Would like to change the current setup to use dspam-milter. May I have some advice on how to change the setup to use dspam-milter?

Note: I haven't really used the thing for a few (I think 2-3) years now, as after a while, I've found resource drain of dspam (using pgsql as a backend) a bit too much for very little need for it that there was.
(iirc it was cpu usage of pgsql once db got big enough, given very limited hw power, but it probably could've been trimmed/compacted/optimized greatly, given the inclination)

Things aren't changing that fast in the world of email though (sendmail milters in 2017!), so it probably works just fine, and should be safe to try in config, as in the worst-case mail will be delayed until milter is disabled again (if not working).

How about the training setup when dspam gets it wrong? Would it be the same as the current setup?

From a brief look - yeah, I think your current setup for these two recipient-paths should work just fine.

I haven't tinkered with postfix setups in a while, but fairly sure only downside there might be lost spam/ham information if running that command fails for some reason (e.g. os limits, segfault, stuff like that).

Didn't add option to use milter for such paths (which should avoid issue above), as I had train-script running from crontab using specific maildir folders, but it shouldn't be hard either - just passing extra options to dspamc here: https://github.com/mk-fg/dspam-milter/blob/c39db13/dspam-milter.py#L142

I'll add a cli option for passing whatever arguments to dspamc binary there, I guess.

from dspam-milter.

Should be possible to use separate milter instance for these paths, started with e.g. ./dspam-milter.py --dspam-opts '--class=spam --source=error' (and feeding mail to /dev/null after that), as of 43d933e

As noted, don't actually use the thing myself though, so didn't really test this change (and pointless dependency dropped in a50ae14), but it's rather trivial so should probably work.
Would appreciate if you'd report any errors/bugs there, if you'll end up trying the thing out.

from dspam-milter.

from dspam-milter.

This error from dspam-milter.
...
milter_id = cls.milter_id_format.format(milter_id)
ValueError: zero length field name in format
...
I hope you can share with me, what I am doing wrong.

From that error, I think the answer is "running it under Python-2.6".
You should be able to check by simply running "python2" and see the version output on the first line.

milter_id_format = '{:04d}' format should only give that error there, where only {0:04d} and such were acceptable.
Even though I wrote the thing a few years ago, didn't have 2.6 anywhere back then for years, as 2.7 came out way back in 2010.

I might not remember all the quirks of 2.6 vs 2.7, but looking at the code, I suspect that this minor "{0} vs {}" formatting issue is the only incompatibility, so tried to fix that in 638440c (only used in a few places), maybe try the updated version.
As you can probably see from the script, pretty much all the code there runs for every email processed, so I think it's likely that if it works fine for one, there will be no other incompatibilities popping-up later.

Other fix, of course, is to run it with python-2.7.
If you have it installed alongside 2.6, just have 2.6 symlinked to "python2", maybe simply change shebang line on top of the script to #!/usr/local/bin/python2.7 or such.
Note that you'll need pymilter module installed for python2.7, as different-version pythons don't usually share their "site-packages" dir (unless PYTHONPATH env-var is used, or something like that).

Fairly confident that it's an issue due to 2.6 because of that fairly unique ValueError: zero length field name in format error - iirc 2.5 didn't have str.format() at all and 2.7+ all allow {}.

from dspam-milter.

from dspam-milter.

The settings done was to have the [SPAM] tagged in the subject and the signature in the body of the email too.

Unless I'm misunderstainding something, afraid this script doesn't work like that at all.

Milter can definitely modify headers or body, but this particular script only runs dspamc --deliver=summary ... on an email, which prints single X-DSPAM-Result: ... header-line, which script then adds to email's headers, as is also written on the first lines of the README.

I.e. it never allows dspam to do anything with email, except provide that one verdict line.
And this is very intentional - I never wanted to allow dspam to edit email as it pleases (and e.g. mangle/loose it on any bugs/crashes), only provide that one header (essentially yes/no flag) to filter stuff by.

But you can probably filter stuff by X-DSPAM-Result instead of mangled "Subject:", and it also contains signature, i.e. should look something like this:

X-DSPAM-Result: dspam; result="Innocent";
  class="Whitelisted"; probability=0.0000; confidence=1.00; signature=...

So again, only place where email is changed in this script is this one line - https://github.com/mk-fg/dspam-milter/blob/638440c/dspam-milter.py#L189 - where single header from dspamc --deliver=summary gets added, simple as that.

For now I will have to ask dspam forum on how to setup dspamc to listen to the dspam.conf.

As mentioned, unless I'm misunderstanding something above, it's not an issue with dspam at all, but just how this script works by design.

I am using dspam with pgsql. So far it is very good. Does not seem to take much cpu.

Should've said "i/o" there instead of "cpu" - typo.

And yeah, in my case it was running on a very modest miniITX atom board, 1G RAM and old hdd, so was probably just my issue, not to mention that dspam might've improved greatly since then.

Though if you're just starting using/training dspam, it should definitely be blazing-fast of course, as it only accumulates large amount of data over time.

from dspam-milter.

single header from dspamc --deliver=summary gets added, simple as that.

Also note that if dspamc command returns anything other than "X-DSPAM-Result: ..." header/line, TEMPFAIL result will be returned to postfix, resulting in later delivery retries.
https://github.com/mk-fg/dspam-milter/blob/638440c/dspam-milter.py#L183-L185

Wanted to point it out in case you might be adding any custom options via --dspam-opts that might change that behavior.

from dspam-milter.

Just sharing.
I am trying out rspamd from rspamd.com.
It is really cool stuff. Very good results. Much more features than dspam.
Really worth a look.
Milter is builtin by the way.

from dspam-milter.