[quote user="Thomas R. Stephenson"]Not really sure how much good they will do for most people.[/quote]You could say the same thing about any proposed feature; that doesn't mean the feature lacks value.  In any event, I think it would be VERY useful to at least be able to apply transaction-level filtering to ANY header, even if we must (for now) forego examination of the actual message body.

[quote]The transaction filters generally work on the SMTP mail headers[/quote]But, as it stands now, only a small predefined subset of them.  That's the problem.

[quote]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.[/quote]I think that in place of "normally", the term "traditionally" is the better fit -- but the traditional approach does not really serve us very well in the here and now.

[quote]I know it's legal to do it this way but it's messy.[/quote]So what's your alternative?  The point here is, issuing a "250 Data received OK" and then realizing you've got a spam/virus/whatever on your hands is even messier.  As explained in my original post, that leaves you on the horns of a no-win dilemma.  No matter what you do at that point, it's going to be wrong in some way -- perhaps seriously wrong in the case of "backscattered" spam (or worse, viruses).  The only truly clean solution is to not "accept" that mail in the first place -- which brings us right back to doing ALL the tests before issuing the "250 ...".

[quote]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]Cool!  That definitely give me some encouragement; but it doesn't really address the primary issue I posted about.

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 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.