supported Sieve Extensions....
I have not been able to find a definitive list of supported Sieve filter extensions. In particular, I am looking for an extension that will let me replace or rewrite a particular header in the message (specifically, the subject line of the message). The RFC lists just the basic actions, and the admin guide mentions a few related to Spamassasin functionality, but from reading the forums it seems that at least "addheader" is supported.
Has anyone here had any experience using sieve filters to replace the subject line of a message? The "addtag" command will let me modify the subject line, but does not let me replace the subject in its entirety, which is what I need to do. I've found lots of proposed RFCs for sieve extensions, including "deleteheader" and "editheader" but the best answer I have found so far regarding messag server support for them is "we try to support what is in the RFC", which is somewhat vauge to me.
Is there a command I can run that will list all the supported sieve commands?
Thansk in advance for any help!
BTW - I am running this version of MS:
bash-3.00$ sudo /apps/msg_inst_dir/SUNWmsgsr/sbin/imsimta version
Sun Java(tm) System Messaging Server 6.2-7.05 (built Sep 5 2006)
libimta.so 6.2-7.05 (built 12:18:44, Sep 5 2006)
SunOS uslcsec05 5.10 Generic_118833-02 sun4u sparc SUNW,Sun-Fire-280R
# 1
one added thought - would doing something like deleteheader "subject"addheader "subject" "my new subject"be supported? (I know the syntax is probably off in the above example, but in general would that be the approach to take?)thanks
# 2
"Draft"s are unlikely to be supported.Final RFC's are much more likely to be so. We claim to support all valid RFC's, but we don't typically try to support drafts, as they're a moving target. Our developers are heavily involved in the IEC, drafting such RFC's, and are pretty good about coding stuff when it's finalized.
Since "deleteheader" is a draft, it's not likely to be supported in any current version.
# 3
Thanks for the info, thats sort of what I gathered. Given what you have said, where can i find a definitive list of the supported sieve commands. There doesn't seem to be such a list in the documentation for MS.
Also, I am still trying to find out if it is possible to modify headers via the sieve language. In a related posting you (jay) implied that it was possible but didn't specify how that would be possible.
To recap, what I want to do is filter messages by their subject line and sender (which I can currently do via sieve). Once identified, I need to rewrite the subject line and also the "from" header and forward the message on to its destination. If I am not able to modify headers via sieve, then it seems like what I need to do is just filter the messages and forward them to a private mailbox, where I would then use some outside code to monitor this box, read the messages, rebuild based on the subject and from, and send them to their original destination.
thanks....
# 4
No, we don't actually document the RFC. However, the IETF does maintain RFC's online.
Since I gave up programming many years ago, and doing Sieve is very like programming, I honestly don't have a clue if what you want can be done, today.
Perhaps if you describe what it is you're trying to do with changing the header, I could offer you some other options.
# 5
Basically, I want to use sieve filters to sort messages, and based on the sort criteria, then I want to create a new subject line for the message. From what i can tell, sieve would be the way to go, except that the deleteheader extension is not supported and it seems that i need this in order to accomplish what i want.
# 6
This is nearly the same thing as you said before, "I want to replace a header". . .Now, sort, that's a whole different thing.How about sorting, by delivering to a different folder? You can easily do that with Sieve, without rewriting any of the headers.....
# 7
ya, sorting is easy enough. In fact, sieve programming is pretty easy in my opinion. The thing is, based on the sort criteria I have to customize the subject line. Don't ask why, im suffering under externally imposed constraints and personally think that I am being asked to use the wrong tool for the job, but suc is the life of a developer 8-). To make things more interesting, the intended recipients of these messages are not even users on my server, basically I am serving as a relay....
Unless someone can enlighten me or show me what i missed in the docs, my final solution is probably going to look like this:
1). Create a "special" msg center account, with a set of folders corresponding to my sort criteria.
2). create a sieve filter that filters the messages I am interested in into this "special" users mailbox via a "redirect" action.
3). create an external process, which periodicaly reads this "special" users mailbox via IMAP, looks at the messages, copies the body, builds a new set of headers containing the original destination email address, and the newly customized "subject" header, and then sends them out, most likely via our corporate SMTP gateway.
just a little background, message center in our case has been implemented as an internal email messaging system for users of our website. Its not a corporate email tool and in general has been locked down (via config and ui modifucation) to prevent its use as such. You may remember me as the guy who wanted to know the best way to perform external email notifcation for message center users. I was successful, thanks to your help and also help from shane, and am happy with the resulting system that was implemented. I'd be happy to share the details or write up a how-to if you or anyone cares.
thanks for all your help, the duke points belong to you...
-mike
# 8
I dunno if this will help you, but Messaging 6.3 does have a "milter" interface.Limited, but available. . .It's due out in a month or two.
Other than that, you have available the "pipe channel" that can route selected messages to an external program, the conversion channel that routes mime parts, the "alternate conversion channel" that routes entire messages . . .
Your proposed method feels pretty complex to me.
# 9
Thanks for the info, I'll look into the milter stuff to see if that may give me a better fit in a future revision.
You right about the pipe channel, I realized after my last posting that combing sieve with a pipe channel would be a more lightweight way to go, and I am mostly done with my current implementation of that now.
Are there any tips you might have regarding the scalability of sieve or the pipe channel? Do you know if every message that goes out to the pipe channel spawns a new process? I vaugely recall there were some options for throttleing the number of messages processed in a given time frame, would that be the best way to make sure I don't kill my server if some clown in the HR department decides to blast out a few thousand messages at once? 8-)
thanks again for your help and advice, I really appreciate it.
-mike
# 10
Sieve on a user basis is pretty lightweight. Sieve on a server-wide basis, since it has to process every message will cause some performance issues.
Your pipe stuff, since it's only messages for this one mailbox shouldn't be a big deal. It's not like the conversion channel, where everything has to start up for each message.
Worst case, if some clown in HR sends your mailbox 109k messages, they'll queue up, and get processed as the server can. In the pipe queue.
# 11
Hi,
> Thanks for the info, I'll look into the milter stuff
> to see if that may give me a better fit in a future
> revision.
The milter plugin should prove to be very powerful. Recent updates to the pre-release 6.3 code (which I *really* hope make it into the release version) now provides support for basically all of the milter email actions including:
- Add headers (SMFIR_ADDHEADER)
- Change body chunks (SMFIR_REPLBODY)
- Add recipients (SMFIR_ADDRCPT)
- Remove recipients (SMFIR_DELRCPT)
- Change or delete headers (SMFIR_CHGHEADER)
- Quarantine message (SMFIR_QUARANTINE)
Writing a milter server (the MTA is the milter 'client') is pretty straight-forward if you have any C-code experience. There are any number of examples on the internet that you could work with.
> You right about the pipe channel, I realized after my
> last posting that combing sieve with a pipe channel
> would be a more lightweight way to go, and I am
> mostly done with my current implementation of that
> now.
This is good approach. Sieve should be used to cut down on the messages to be processed as it is light-weight and fast, and then the pipe channel can handle the rest of the actual 'heavy lifting'.
> Are there any tips you might have regarding the
> scalability of sieve or the pipe channel? Do you
> know if every message that goes out to the pipe
> channel spawns a new process?
Yes it does. Which is why you need to limit the messages that end up in the pipe channel to just those that you need to end up there.
> I vaugely recall there
> were some options for throttleing the number of
> messages processed in a given time frame, would that
> be the best way to make sure I don't kill my server
> if some clown in the HR department decides to blast
> out a few thousand messages at once? 8-)
The pipe channel can queue up messages. You can limit the number of 'jobs' by using a job pool (defined in job_controller.cnf file and set in imta.cnf).
> thanks again for your help and advice, I really
> appreciate it.
Good luck with your project. It is always interesting to hear how customers are using the product.
Regards,
Shane.
