Atomicorp

I had the same problem after upgrading to psa-proftpd 1.3.2 - could not log in via FTP.

Removing the following lines from /etc/proftpd.include fixed it:
Question is - am I now missing something for having removed these lines?

It would help to know what kind of error you are getting when trying to access the site. Could it be a DNS problem? If your ISP caches DNS entries for an unusually long time, you could have a DNS problem on your server that you personally may not notice for a while.

One feature that was discussed but (as far as I know) never implemented was integration with POP-before-SMTP relaying, so that any IP on the relay list would NOT be rejected initially by qgreylist.

That's the one reason I don't use greylisting at all - I have a lot of clients using POP-before-SMTP.

Thanks, breun - good to know. I had problems years ago with bind-chroot, but I wasn't aware that caching-nameserver could also cause trouble. I have removed it completely.

Oh, sure - if you want to do it the easy way. I prefer to research vague error messages and run down rabbit holes for a couple of hours first... What threw me off was that I updated it yesterday, and everything was fine. Then suddenly it quit working today. I now realize that it actually did quit wo...

CentOS 4, Plesk 8.4 Yesterday, I updated caching-nameserver and freetype. Today, all of the sudden, Bind just quit working. I tried to restart it, and got a message about rndc.key being missing or invalid, so I followed some instructions I found to regenerate the key and update named.conf. Now, name...

I have been with 1and1 for years, and I would say that their product is great, their prices are great, but their support leaves something to be desired. Fortunately, I only have to call support about once every couple of years. Example: just last week I had a problem where I and several of my client...

I had (possibly) this same problem, and when I tried to restart clamd, it complained about not being able to read the log file. I changed the owner of all the files in /var/log/clamav/ to be clamav:clamav, and that fixed it. I've read elsewhere that these logs need to be owned by qscand, but my inst...

I'm not using TLS/SSL, so I'm not sure if this is related or not, but I was having a lot of timeout issues, and even cases where one FTP client could connect and work (albeit slowly), while other clients could not connect at all - even from the same machine. The problem turned out to be that I was u...

Aha - thanks exi1ed0ne. That revealed something entirely different: # sa-learn --dump magic --dbpath /var/spool/qscan/.spamassassin 0.000 0 3 0 non-token data: bayes db version 0.000 0 1290838 0 non-token data: nspam 0.000 0 97177 0 non-token data: nham 0.000 0 177340 0 non-token data: ntokens 0.000...

Here's what I'm doing: # sa-learn --dump magic /var/spool/qscan/.spamassassin 0.000 0 3 0 non-token data: bayes db version 0.000 0 212 0 non-token data: nspam 0.000 0 1899 0 non-token data: nham 0.000 0 82770 0 non-token data: ntokens 0.000 0 963261639 0 non-token data: oldest atime 0.000 0 12118783...

So, are you saying the stats should be increasing as it autolearns? Because mine is not doing that.

The bayes db is there, and it gets updated when I use sa-learn manually, it's just not updating via autolearn. Do I have to specifically set that up? If so, where?

Thanks.

I see in my mail log that spamassassin claims to be autolearning messages (as expected), but when I look at the stats (sa-learn --dump magic), I don't see the number of ham and spam messages increasing. Should it be? Does spamassassin keep its autolearn data somewhere besides the bayes db?

Never mind - I figured it out.

I used tcpdump to watch the transaction, and it was the old bare LF problem (http://cr.yp.to/docs/smtplf.html). Apparently, they are not capturing the response sent by my server to their malformed e-mails.