I have been having a similar problem, although not with spam from a specific sender, and had wondered if some of the mails which were not being scanned by Popfile were missed because the server was too busy since it is only a single core single CPU system.   However I had a quick look at one example today and noted that it was 58 K in length and that my -s setting was 50.   I have now raised this to 100 and await developments.

There goes my reason for hassling my bosses for a spangly new server!

I have been using Popfile along with Mercury with great success for years, however, I have one perplexing issue.

 For some reason, there is one spammer that is (somehow) bypassing popfile. His messages appear in my mailbox and the headers do not show any Popfile classification. The messages do not appear in the Popfile history as being classified or reviewed. In my Mercury log they appear as having been received. It appears that Mercury (for some reason) is simply not sending these messages to Popfile for classification.

Has anyone run into this sort of thing in the past? Is there any setting in Mercury that I could have damaged inadvertently that causes it to exempt these messages from being sent to popfile for classification?

Can't say it's the same thing, but I have seen spam get by our filters when they use one of our email addresses in the "Return-path" header.

Mercury (4.01c at least) seems to think it originated as an internal email and skips the filtering.
I've added a rule where if the "Return-path" header has one of our email addresses and the "From" header doesn't, to add weight to the email.

Tony

[quote user="webjack"]

I have been using Popfile along with Mercury with great success for years, however, I have one perplexing issue.

 For some reason, there is one spammer that is (somehow) bypassing popfile. His messages appear in my mailbox and the headers do not show any Popfile classification. The messages do not appear in the Popfile history as being classified or reviewed. In my Mercury log they appear as having been received. It appears that Mercury (for some reason) is simply not sending these messages to Popfile for classification.

Has anyone run into this sort of thing in the past? Is there any setting in Mercury that I could have damaged inadvertently that causes it to exempt these messages from being sent to popfile for classification?

[/quote]

First are you sure that this spammers messages are not too large for your size setting in POPFile?   Second, if you are using any sort of  popfiled.rxp settings these may be allowing the sender to bypass the POPFileD classifications.

Thank you very much, Thomas. There is a popfiled.rxp file in my Mercury directory. So this is probably the cause of the problem. The contents of the file are as follows:

# Sample Regular Expressions for mydomain.com
# Note comment lines. The Daemon does NOT like blank lines in this file.
#
# Do not check new mail from an internal sender
# Must be From: "xxxx yyyy" <zzzz@mydomain.com>. I don't allow digits.
# I also require the Organization Header and require all my users to
# use Pegasus 4.12a.
#
if From: "[a-z]+ [a-z]+" <[a-z]+@mydomain.com>
and Organization: Phlebotomy Associates, Inc.
and X-mailer: Pegasus Mail for Windows (v4.12a)
#
# Do not check mail bounced by internal sender to someone else
# This rule works because my users all use Pegasus. YMMV.
#
if Resent-from: "[a-z]+ [a-z]+" <[a-z]+@mydomain.com>
and Resent-to: *
and Resent-date: *
#
# Mail that is automatically resent by a Mercury/32 Forward file
# I don't allow digits in my user names. I also don't use first
# names - it's more professional and hinders dictionary attacks.
#
if Resent-from: [a-z]+@mydomain.com
and Resent-Date: *
and X-Autoforward: 1
#
# Mail trapped by DNSBL is spam
# I configure Mercury to insert an X-Blocked: header after a DNSBL check
#
if X-Blocked: *

I tried changing the extension on this file so that it would not be found and interfere. The result is that now all internal mail is being filtered through Popfile. I really don't want to go thru and create a magnet for each and every user and then have to maintain them everytime people come and/or go. Is there an intermediate approach?

I'm not really the one to answer this question for you.  I send all mail via the Mercury queue and so this is no big deal for me.  In any case if your POPFileD startup line says to use this file then you should go through and fix it so it matches your  domain  requiresments.  Are you really using WinPMail v4.12a?  Is your domain actually mydomain.com?

Hmmmm. It has been a long time but I believe I simply installed the default configuration of popfile. Looking at it now, you are obviously correct. The .rxp file is simply the demo file that came with the release and bears no resemblance to our installation. Therefore, it would seem that it could not be responsible for giving a free pass to these emails. So that puts me back to square 1!

When you say you send all mail via Mercury queue, I believe we do also. When you hit the send button in Pegasus, an E------.101 file appears in the Mercury queue directory. Shortly thereafter MO-------.QCF and MO------.QDF files join in and then, as the mail is processed, they all disappear. However, are not these scanned by Popfile?

In any case, although this is an interesting academic question, for practical purposes, I think I will just blacklist the domain these emails come from and be done with it. (Or is this being naive?)

> Hmmmm. It has been a long time but I believe I simply installed the
> default configuration of popfile. Looking at it now, you are
> obviously correct. The .rxp file is simply the demo file that came
> with the release and bears no resemblance to our installation.
> Therefore, it would seem that it could not be responsible for giving
> a free pass to these emails. So that puts me back to square 1!

Not necessarily, that file is giving a free pass to some mail based on a domain or other factors in the message.  You might try running without it and see what happens.

>
> When you say you send all mail via Mercury queue, I believe we do
> also. When you hit the send button in Pegasus, an E------.101 file
> appears in the Mercury queue directory. Shortly thereafter
> MO-------.QCF and MO------.QDF files join in and then, as the mail
> is processed, they all disappear. However, are not these scanned by
> Popfile?

Correct.  It's not a Fxxxxxxx.101 though, it's simple 8 hex numbers.101.  I'm not sure they are not scanned by POPFileD.  That's why you would use the .RXP file to bypass the local mail based on something it the 101 message files.


>
> In any case, although this is an interesting academic question, for
> practical purposes, I think I will just blacklist the domain these
> emails come from and be done with it. (Or is this being naive?)

You really should try and figure out why they are not being processed by POPFileD though.  The only reason I do not get mail processed by POPFileD is when it's over the size limit I set for a message.

Well, in the interests of advancing the enlightenment of humanity in general (wow! I feel like I have found new purpose in life), I have done some further investigation... and still come up short. 8-(.

I sent a message from the office to my home address and then checked the headers on the message received at home. They clearly contained the headers:

X-Text-Classification: not_spam

X-POPFile-Link: http://nemcbdc:9090/jump_to_message?view=452630

So, I am convinced that outgoing mail is going thru Popfile.

The offending messages are not greater than our size limit.

I took the .rxp file out of the mix but did not get any of the offending messages yet to test. (They are not a regular occurence. Only happens every couple of weeks. This really is an academic problem, not a pressing operational issue).

So we will see what happens.

The only tool in PopFileD to prevent it from scanning outgoing email is the .rxp file - that's why it was created, I didn't need my. You need to edit it to match your configuration, and put it back in. Otherwise your outbound email will be scanned by PopFile.

Thank you all for your help. If only I had read earlier posts with a more open mind, I could have resolved this sooner.

One of the first posts mentioned that files over the size limit were exempt from popfile processing. I assumed the writer was talking about the size setting in Mercury configuration (because I was not aware of any other). Looking back on it, that was pretty foolish thinking because, if the message was being filtered out by Mercury's size limit, it wouldn't be showing up in my mailbox to bother me.

While stumbling around I came across the DAEMON.INI file with the call to popfiled. Lo and behold, there I saw the -s switch and realized that there is a size limitation in the popfile parameters (how dumb can I be?). A little review of the popfiled documentation confirmed my ignorance. So I have upped the size limit and will await this spammer's next attack to see what happens.

 In the meantime, I have revised my .rxp file to actually do something (hopefully what I want), have expanded my understanding of the connection between Mercury and Popfile, and deepened my appreciation of the need to listen to the more experienced members of this forum with greater care (and humility).

Very much thanks to Thomas and Subelman.