Marcin Krol wrote:
> Hello Heiko,
>
>>> if (!string_vformat(process_info + len, PROCESS_INFO_SIZE - len, format, ap))
>
>> Seeing this I'd say you can safely ignore the message. But probably it's
>> connected to your problem, since the length (number of arguments) for
>> the pipe command might be limited as well.
>
>> How do you expect the pipe command to look like? Do you have some
>> example?
>
> Sure:
>
> mailfilter:
> driver = pipe
> command = /etc/domeny/mailfilter -u ${lookup{$domain}lsearch*{/etc/virtual/domainowners}{$value}} -d $domain -l \"$local_part\" -s $message_size -a $sender_address -m $message_id -c $rcpt_count -t $received_protocol -p $pipe_addresses
> current_directory = "/tmp"
> group = mail
> home_directory = "/tmp"
> log_output
> message_prefix =
> message_suffix =
> return_fail_output
> no_return_path_add
> user = mail
>
> Since this script does my custom spam filtering, I really, really need all those variables, in fact I'm going to need more of them.
>
> Esp. $pipe_addreses might be _really_ long list, considering what some mailing list software we have to host is doing - it often tells Exim to deliver a mail with, say, 300 recipients.
You may actually run into a OS/shell limitation after you try to extend
the exim one. There is a limit on the length of commands there too but I
don't know if off hand. I have run into it before though when trying to
pass lots of arguments to programs.
If there are many many options, you might be better off putting them all
in a file that your program parses while the mail body is passed via the
pipe. Might be counter intuitive but it will prevent hitting the overflow?
--
The Exim Manual
http://www.exim.org/docs.html
http://www.exim.org/exim-html-current/doc/html/spec_html/index.html