lhite

good to know that SA here is the latest and greatest -- i guess it will remain a mystery as to why it seems to be so inconsistent at times. i know that a lot depends on how you configure it, but in this case that's not relevant. one day it was not catching anything, then all i did was change the POP to SSL -- didn't even go in to cpanel -- and literally within hours i had an email from the client saying that the spam problem had virtually disappeared all at once. cue Rod Serling.........

can someone explain this to me: i have a client who has a terrible spam problem -- literally 200+ spams per day. spam assassin has been totally ineffective, typically filtering under 10 a day. then last week, for totally unrelated reasons, we decided to convert all their email clients to use SSL mail, both POP and SMTP. and all of a sudden SA starts working like a charm, with something like a 95%+ hit rate! i really don't believe in coincidences like this -- something had to have happened. and yet, how would changing how the email is retrieved change how SA is working? is anyone here familiar enough with the inner workings of SA to explain this to me? as a side note, i've had to move several clients off TCH because of spam issues and the lack of any effective tool here to deal with spam. now i wonder if converting to SSL POP is all i had to do? i've talked to a lot of people who use SA at different hosting companies, and they think SA is great -- it's only with my accounts here at TCH that i seem to have problems. and i notice there's a post here from last month (subject "Spam Assasin?") that echoes the same types of problems i've had with it in the past. could it be that the "key" to using SA is to always configure your POP for SSL, and that's what everyone else is doing out there who has success with SA? if so, sure seems like a well kept secret as i can't find any such advice using The Google Machine. lee

thanks -- that explains what i'm seeing. the auto delete option was on, so i'll turn that off so i can see exactly what all SA is catching, which will give me a better idea of how well it's working.

i'm trying to figure out why SpamAssassin seems to be so ineffective at TCH. i have a domain hosted elsewhere which also uses SA, and it seems to do a better job -- although still far from what i would like. at the other service, SA outputs a header record indicating that the SA version number is 3.3.1, but i get no such header here. what version of SA is running at TCH? could it be an older version, perhaps? i also notice that the SA Configuration page is a bit different -- for example, at the other service there's a "rewrite header subject" option that i don't see here. again, maybe symptomatic of an older version being implemented here?

yep, my site has been hacked as well. this time appears to be worse, as my cpanel password has been changed and i have no ftp access. argh.

it's always the simple solutions that drive you up the wall..... problem was that in the dump file, you need to change the name of the database so that it is prefaced with your control panel user name, as that's the way all the databases are named on the TCH server. the first two lines of the dump file will typically look like: CREATE DATABASE IF NOT EXISTS `milb` /*!40100 DEFAULT CHARACTER SET utf8 */; USE `milb`; you edit the file and change the database name to what the TCH server expects: CREATE DATABASE IF NOT EXISTS `xxxxxxxx_milb` /*!40100 DEFAULT CHARACTER SET utf8 */; USE `xxxxxxxx_milb`; where xxxxxxxx is your control panel user name. from there everything works fine!

will do -- thanks!

i'm trying to import a MySQL database with phpMyAdmin and am getting an error message: #1044 - Access denied for user 'xxxxxxxx'@'localhost' to database 'milb' where xxxxxxxx is my control panel user name, and the user name with which i logged in to the control panel. how do i get past this access error?

crickets........ ok, i've been digging around the internets and best i can tell no mail server can block this type of email verification. now the VRFY command referenced at the network-tools.com site can be blocked. but you can accomplish the same thing via the RCPT TO command, which is exactly what the tool there does, and that command cannot be disabled (i'm guessing if it were, the whole SMTP process would fail to work). however, just because that tool says that a given email address is valid, does not necessarily make it so -- if the mail server is configured with a default address to use for all unrouted mail, then that tool is essentially going to "accept" any and all email addresses regardless of whether an actual mail box exists for that address. so if you are using that tool to verify email addresses, if an address fails you know that it's invalid -- but if an address passes, you don't know for sure whether it's valid or not. now what i was looking for is a way to block such a tool from seeing that a given valid address is in fact valid. but alas, that doesn't seem possible -- not at TCH or anywhere else. for any valid email address, the RCPT TO command will always tell you it is valid.

i'm not sure i'm following you here -- you are talking about the TCH server being able to verify an email address on a remote server (in your example, newyorktimes.com). i'm talking about a third-party being able to verify an email address on a TCH hosted server. seems like those are two totally different functions.

i'm looking for a way to block programs from verifying if an email address is valid. there are lots of tools out there that purport to do this -- for example, see network-tools.com. select the "Email tests" button, and you can use that to check if a particular email address is valid or not. according to their FAQ, however, most email servers have this feature blocked. but alas, it's obviously not blocked on my TCH server. is there a way via CPANEL to turn this feature off?

yes you did, and thank you! i wasn't going to mention that on a public board as i didn't want to be responsible for a slew of other users demanding that their server configuration be changed as well. and yes indeed, TCH Rocks!

just found out from tech support that there is indeed a 5000 character limit on how much of the email message is processed in the filter evaluation -- so that explains why my filters were occasionally failing. the part of the message that triggered the filter was beyond the first 5000 chars. this limit is set at the server level, and so on shared servers, there's no way to change it at the individual web site level.

ok, did some more testing and i think the problem is related to the length of the message. i can test the filters with just the message itself and the filter works. but then i can just add some arbitrary text in to the middle of the message, forcing the point at which the filter hits further down in the message, and that will cause the filter to fail. so...... it would seem that the filters are only applied to the first X characters of a message (and X appears to be right around 4096 based on my limited testing). if that's true, is there anyway to increase that number? or any way to tell the filter to at least ignore the header stuff?

interesting -- when i test the filters with the entire message including the header, it does indeed fail to work properly. but it's not because an earlier filter triggers first. i get the message that "Filtering did not set up a significant delivery. Normal delivery will occur". when i test with just the message body, it works as it should and i get the message "Filtering set up at least one significant delivery or other action. No other deliveries will occur", which is exactly as it should work. it's as if something in the header is causing the filter evaluation process not to work the same as when the header is not included. like maybe something in the header is causing the evaluation process to abend. i'm also getting a message in the filter window saying "**** debug string too long - truncated ****" -- i get that in both cases, using the header or not using it. what does that mean? it doesn't really tell me where the string is truncated, or for that matter what string it's referring to. and in this particular example, the filter will hit about 40 chars from the end of the message, so it would seem that the "truncated" message is not relevant.