RE: New fields in control files?

[Marek Kowal <marek.kowal@portal.onet.pl>]

Hello?

Is there anybody out there? ;-) Please, respond... ;-)

In the meantime, another solution came to my mind (so its the third one): I
could store the information directly in the message headers. But doing so
from the router level means that I would have to rewrite the whole message
in the router directory, preserving its name. Certainly, this is not very
effective. But then, hey, there is the control file with brand new header,
which is created by router at the end of the message processing, and that
header is replaced with the original one by each TA. But HOW can I influence
it at the router level? Is there any command in zmsh which allows me to put
some contents in the newly-created header?

Cheers,
Marek.

> -----Original Message-----
> From: Marek Kowal [mailto:marek.kowal@portal.onet.pl] 
> Sent: 24 kwietnia 2003 19:12
> To: zmailer@nic.funet.fi
> Subject: New fields in control files?
> 
> 
> Hello,
> 
> I would like to install some message content processing programs in
> zmailer's router. They take a file path to the filtered messages as an
> argument, and based on its contents, they return specific 
> numbers, which
> will be required at a later stages of processing, when TAs 
> take care of
> them. One obvious application of such a model is anti-spam 
> processing, also
> anti-virus checking and so on.
> 
> Now the question arises, how to store the data returned by 
> programs in such
> a way, that they become avaliable to later stages of processing, i.e.
> scheduler or TAs. 
> 
> One solution would be to create another directory structure 
> in postoffice
> directory, and keep the information there, naming files with 
> the output of
> the program in the same way as in is named in router 
> directory (something
> similar to transport directory). This involves some additional IO (the
> router process has to create one file in transports directory 
> already, this
> would be the second one), but seems to be easy to program.
> 
> The other way is more "fundamental" ;-) store the informatin 
> directly in the
> the control files located in transport directory, which are 
> associated by
> router with each message. Those fields are already avaliable 
> in TAs (via
> ctldesc struct), so the whole idea seems to be more 
> strightforward. Also
> there is less IO involved in such setup.
> 
> What do you think of that idea? If you do not find it stupid, 
> how should I
> proceed? First, obviously, I have to redefine the ctldesc structure,
> ctlopen() functions etc. Then there goes the question of 
> accessing those
> data fields from router - how to set them from zmsh? Now that 
> I wrote it,
> this seems like a hard work and probably first solution would 
> be much easier
> to implement. But still, I would like to hear your opinions.
> 
> So I'm hoping to hear from you ;-)))
> 
> Cheers,
> Marek.
> -
> To unsubscribe from this list: send the line "unsubscribe zmailer" in
> the body of a message to majordomo@nic.funet.fi
> 
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi