[quote user="Sailor21"]
Hi --
I'm still running Mercury/32 v4.01b/c because, after eagerly downloading 4.5x, I found to my great disappointment that the ONE thing I was most anxiously waiting for was NOT among the various features added, despite the fact that it was requested/discussed long ago on <comp.mail.pegasus-mail.misc>. Add to this the change in licensing terms (which seems to have "caught me in the middle", so to speak -- but I digress), and the net result was a giant "Whoa, Nellie!"
The feature in question seemed (and seems) so obvious and fundamental, that it really surprised me that it wasn't included. What I'm referring to here is a fix for the extremely limited ways in which Transaction-Level Filtering can be applied. As it stands, I can't even test all the message headers, let alone the body, before being forced to either accept or reject the message. And since I cannot (yet) run some of the tests which might tell me that the message ought to be rejected, I have no choice but to accept it. At that point, I can run further tests, particularly as defined by the Global Filtering Rules; but even if/when one of these tests produces a positive result, I face a no-win dilemma: I have to either silently drop it on the floor (which is not a good idea in the case of messages from legitimate senders which happen to get trapped in a filter for some "inadvertent" reason -- such as containing a banned attachment type, for example), or generate and issue a bounce message (which is also a bad idea, particularly if the sender is off-site, since it can lead to propagating "backscattered" spam or worse -- and that is becoming less and less acceptable by the world at large with each passing day).
At the very least, the ability to create Transaction-Level Filtering rules based on ANY message header (such as, for example "X-Mailer:", which can be a very reliable spamsign) is desperately needed. But beyond this, it seems to me that ALL of the functions currently provided by the Global Filtering Rules should be applicable before MercS issues the final SMTP code (be that a "250 Data received OK", or a 5xy code of some sort, as called for by the instant situation).
I know this is (or at least "should be") do-able, as other MTAs do manage it. I was hoping to avoid (at least for awhile longer) having to make such a migration, due mostly to the learning curve it would inevitably bring with it (tho' that said, I would also dearly love to be able to ditch yet another WinBox -- I was greatly encouraged by the mention awhile back of a possible Linux version of Mercury, which I think would be a VERY good idea; but I've not seen any further progress on that front).
So... When can we look forward to usefully expanded Transaction-Level Filtering capabilities?
[/quote]
Not really sure how much good they will do for most people. The transaction filters generally work on the SMTP mail headers and all those thing that happen prior the the DATA command to receive the actual body of the message and the actual message headers. Working on the body of the RFC 2822 message looking for headers means are are in the process of downloading the mail already and normally you would not issue the 500 series error message in this stage of the message delivery. I know it's legal to do it this way but it's messy.
FWIW, I've got Mercury/32 running on Linux (Ubuntu v7.10 with Wine v0.9.50) without any problems at all. I am running Clamwall, Spamwall and Graywall as well.
[quote user="Sailor21"]<p>Hi --
</p><p>I'm still running Mercury/32 v4.01b/c because, after eagerly downloading 4.5x, I found to my great disappointment that the ONE thing I was most anxiously waiting for was NOT among the various features added, despite the fact that it was requested/discussed long ago on &lt;<a href="http://groups.google.com/group/comp.mail.pegasus-mail.misc?lnk=sg">comp.mail.pegasus-mail.misc</a>&gt;. Add to this the change in licensing terms (which seems to have "caught me in the middle", so to speak -- but I digress), and the net result was a giant "Whoa, Nellie!"
</p><p>The feature in question seemed (and seems) so obvious and fundamental, that it really surprised me that it wasn't included.&nbsp; What I'm referring to here is a fix for the extremely limited ways in which Transaction-Level Filtering can be applied.&nbsp; As it stands, I can't even test all the message headers, let alone the body, before being forced to either accept or reject the message. And since I cannot (yet) run some of the tests which might tell me that the message ought to be rejected, I have no choice but to accept it.&nbsp; At that point, I can run further tests, particularly as defined by the Global Filtering Rules; but even if/when one of these tests produces a positive result, I face a no-win dilemma:&nbsp; I have to either silently drop it on the floor (which is not a good idea in the case of messages from legitimate senders which happen to get trapped in a filter for some "inadvertent" reason -- such as containing a banned attachment type, for example), or generate and issue a bounce message (which is also a bad idea, particularly if the sender is off-site, since it can lead to propagating "backscattered" spam or worse -- and that is becoming less and less acceptable by the world at large with each passing day).</p><p>At the very least, the ability to create Transaction-Level Filtering rules based on ANY message header (such as, for example "X-Mailer:", which can be a very reliable spamsign) is desperately needed.&nbsp; But beyond this, it seems to me that ALL of the functions currently provided by the Global Filtering Rules <b>should</b> be applicable <b>before</b> MercS issues the final SMTP code (be that a "250 Data received OK", or a 5xy code of some sort, as called for by the instant situation).
</p><p>I know this is (or at least "should be") do-able, as other MTAs <b>do</b> manage it.&nbsp; I was hoping to avoid (at least for awhile longer) having to make such a migration, due mostly to the learning curve it would inevitably bring with it (tho' that said, I would also dearly love to be able to ditch yet another WinBox -- I was greatly encouraged by the <a href="http://www.pmail.com/sundry/pmlinux.htm" title="mention" mce_href="http://www.pmail.com/sundry/pmlinux.htm">mention</a> awhile back of a possible Linux version of Mercury, which I think would be a VERY good idea; but I've not seen any further progress on that front).&nbsp;
</p><p>So...&nbsp; When can we look forward to usefully expanded Transaction-Level Filtering capabilities?</p><p>[/quote]</p><p>&nbsp;</p><p>Not really sure how much good they will do for most people.&nbsp; The transaction filters generally work on the SMTP mail headers and all those thing that happen prior the the DATA command to receive the actual body of the message and the actual message headers.&nbsp; Working on the body of the RFC 2822 message looking for headers means are are in the process of downloading the mail already and normally you would not issue the 500 series error message in this stage of the message delivery.&nbsp; I know it's legal to do it this way but it's messy.</p><p>FWIW, I've got Mercury/32 running on Linux (Ubuntu v7.10 with Wine v0.9.50) without any problems at all.&nbsp; I am running Clamwall, Spamwall and Graywall as well.
</p>