On Mon, Sep 10, 2012 at 11:13 AM, Vsevolod Stakhov
<vsevolod@???> wrote:
> Hello,
Hello Vsevolod!
> I've seen the topic in this mailing list related to integration of
> rspamd and exim. I'm the author of rspamd and I'd really very
> appreciate if exim will be able to interact with rspamd natively.
I was the one who asked about it, thanks for following up on me. :-)
> As you see there is a patch to src/spam.c for rspamd support:
> https://bitbucket.org/vstakhov/rspamd/src/23df2e6bd3ee/contrib/exim/patch-exim-src_spam.c.diff
>
> This patch is very far from perfect as it breaks compatibility with
> spamassassin and it cannot handle a lot of information from rspamd. I
> can write a new patch to fix these problems, but I need some
> information about exim's design to fit my code for it.
I'll quote a relevant section of the conversation we had when I asked
the original question:
===== Quote
>> It looks like good code to me, so with a little bit of #ifdef we could
>> make rspam vs spamassassin a compile time setting. Or maybe add a new
>> "rspam" condition that calls this code instead of the existing "spam"
>> condition code.
> Compile-time would be a last resort, IMO. rspam is nice, slightly nicer
> is a protocol variant option. Either spamd_options in the main config
> section, to go with spamd_address, or a /modifier for the spam ACL
> condition, much like the /modifiers on malware checks, etc.
> "variant=rspam"? Or just "rspam"?
> I leave the decision on syntax to those doing the work.
===== End Quote
> So here are the questions:
>
> 1) Should I write the new function like
> int spam(uschar **listptr) {...} -> int rspam(uschar **listptr) {...} ?
That's a simple way to get rid of the function conflict, so that part
sounds good.
> 2) Why do you think that push_line function in the current patch is
> not good for exim (it uses writev for effective data transmission)?
It's not that it's "not good for exim", rather it's just different
than the way it's normally done in exim. You chose to use a r +=
push_line() way of adding to a string (adding to a va_item array),
whereas in exim everything else tends to either create it all in one
command (i.e the string_format() in the current spam() function) or
using string_snprintf().
Personally I am not opposed to your method, it's just different and
"new", and so requires some thinking to make sure it doesn't introduce
any security holes. My c-fu is not strong enough to know for sure if
this is the most correct way, I have to defer that to others.
> 3) Can I introduce some new global variables like <spamd_action> -
> this can be useful as rspamd has 'actions': policies for recommended
> action with this email (like 'accept', 'reject', 'add header' etc)?
One of the suggestions by Phil was to add a new global variable or
/modifier (to the spam call) or some other way to indicate the
different calling requirements. A similar method would be required to
indicate the different return requirements. I'm open for conversation
on this one. We need to establish exactly what settings and
conditions to add, and what other configuration adjustments are
needed.
> Anyway, if you think that rspamd support is not worth to be included
> in the mainstream of exim I'd like to know that things to improve the
> current patch, so I'd appreciate any answers and comments.
I think it is worth it to add rspamd capability. Anything that
increases the potential exim user base is welcome as long as it isn't
too much work, it doesn't break compatibility, and it doesn't
convolute the code too much. You already have a patch which means
that the "not too much work" issue is take care of. Changing the
function name partially fixes the "breaks compatibility" issue.
Adding one or two conditions to handle increased capabilities both for
calling and return values is likely the bulk of the conversation and
work to be done.
I look forward to more conversation about this!
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
