efa-project.org

What do you mean, 0 spamassassin rating?

Can you share any of the spam reports?

Without knowing what's getting through that wouldn't have gotten through before, it's hard to say.

Can you tell her if the postfix RBL checks are still working correctly?

There is also the References: header that should also contain the message id. And yes, some email clients will not use the headers correctly. That's ok. It just means we treat the messages as normal and do the normal checks. Doing the header checks is relatively easy. Modifying the message to leave ...

Looking a little more closely at MailScanner, I can see that the message ids are not stored in a useful format, so to make a feature like this possible we would either have to: - change mail scanner to store the Message-IDs (Message-ID: (.*)) into the database that we could then query or - implement...

Interesting idea, so I had a look to see if anyone else has thought of this. There is/was a spamassassin plugin called " In-Reply-To " that is unfortunately no longer maintained and the original website no longer exists. Well, to the wayback machine then! Here is the: archived version , th...

Centos 6.x where x is 8 right now, I think.

Ha! Thanks DaN,

That is indeed the fix. It's been over an hour and the message hasn't returned.

The lesson here is: if you are getting these cron messages, pay attention to them.

- Paul

oops. I just noticed that I'm getting those messages to after upgrading. I didn't noticed until I actually looked. The message is generated by the hourly cron job to show the results. Looking at the message, I've got the following content: Notice: Constant SHOW_GREYLIST already defined in /var/www/h...

Trying to reproduce the problem...

Shawn, is that the best way to run the yum update command? Is this something for the wiki?

Is @domain.com one of the domains served by your EFA box?

the answer to your question is up thread
https://github.com/E-F-A/v3/issues/163

Well, a quick Google search turns up this: http://serverfault.com/questions/728641/blacklisting-tld-in-postfix Another way would be to use spamassassin to look for the domain and score it really high, this way you could verify that the messages are actually spam. There are probably other ways to do ...

Can you tell me the contents of the following files:

• /etc/cron.d/0hourly
• /etc/aliases

I think I know what your problem is, and that information will confirm it.

You could disable spamassassin checks

Why would you want to do that?

quick idea, can you examine the existing rule sets and see if there are any with an or conditional then use that for comparison?

otherwise, it's off to the spamassassin wiki to read about how to write the rules.

Correct, old entries remain forever. Modifed entries are updated and new entries are inserted immediately.

I'm pretty sure the rules are automatically loaded, but I never bothered to find out. I know they can be updated safely, and that's all I cared about.

there are still a few rules without descriptions that I've had to add to my local.cf. For my installation, these are the ones I found missing, or could not find anything at all # missing descriptions? text based on what I could determine from the rule itself describe FAKE_REPLY_C The mail's subject ...

Yes, I noticed this problem before. See here: https://forum.efa-project.org/viewtopic.php?f=13&t=1560&p=5938#p5938 It's also been fixed in the latest head branch of the mailwatch project. When you "Update Spamassassin Rule Descriptions", the rule descriptions are collected from the...

Another solution would have been to setup an iptables rule to accept incoming smtp connections from that provider.

It may have been minor corruption in the log file. Only way to find out is to debug the script on that file.

Glad it's working for you again.

ovizii, that is the place for custom cf amd pm files (at least that is where I am putting mine, but it's not really the place to alter preexisting files (except local.cf) as they were created by other packages. so yes, prexisting stuff (except local.cf hopefully) could get overwritten. new stuff sho...

Well, not exactly solved yet, but one of these days...

As a quick guess, I'd say the variables are not getting set beacause the script is having a problem reading the log file. Verify the permissions as well and also compare the log files between the physical and one of the virtual servers - is it the same format and in the same location?