Re: What blacklists are you using at your MTA?
On Sat, 2 Apr 2011 23:13:45 -0400 dar...@chaosreigns.com wrote: On 04/03, Karsten Bräckelmann wrote: Because they are two different blacklists. Because there is no guarantee being on one prevents being listed on the other. And because these stats are generated in a SCORING system. Yeah but they're in the same DNS zone, zen.spamhaus.org, and although I recognize you can have multiple A records for the same name, it looks like queries to this zone only return one answer per lookup. Or does it sometimes return multiple A records for one query, and I'm just not finding those examples? Here's one: $ dig +short 8.172.193.117.zen.spamhaus.org. 127.0.0.11 127.0.0.4
Re: What blacklists are you using at your MTA?
On 03/04/11 02:24, dar...@chaosreigns.com wrote: I'm curious what blacklists other people are currently using at their MTA, rejecting during delivery, before mail gets to spamassassin. There was a similar thread on this list a few months ago - please refer back to the list archives: 3rd Jan, 2011; Subject: Off topic: best RBLs to use to block at smtp connection?
local.cf permissions
Hello, From what I can tell, it is common to have local.cf permissions/ownership as root:root 644 (rw-r--r--) But I have some database passwords (bayes, awl) in that file and would like NOT to have world read permissions on that file. I'm not entirely sure what process reads that file and what user that process runs as, so I hope that's an easy question you can answer for me. Is there any ownership or permissions combination that is more restrictive than the above? Does it really need to be world readable? Thank you!
Testing new server
Hi all, I've just installed a new server using fedora14 with spamassassin, amavisd, postfix, and dovecot. I've configured it the same to the best of my ability as an existing server currently in production that I would like to replace with this new system. This is a significant upgrade from the current system, so all software versions are different. How can I either use the existing system or emails stored on the current system to test the new system before putting it into production? I'd like to make sure that amavis and spamassassin are configured properly before switching the two systems and learning I've configured something wrong and avoid it rejecting mail, marking it incorrectly, or other possible configuration problems. Any ideas greatly appreciated. Thanks, Alex
Re: local.cf permissions
On Sun, 2011-04-03 at 13:30:44 -0700, Ori Bani wrote: From what I can tell, it is common to have local.cf permissions/ownership as root:root 644 (rw-r--r--) But I have some database passwords (bayes, awl) in that file and would like NOT to have world read permissions on that file. I'm not entirely sure what process reads that file and what user that process runs as, so I hope that's an easy question you can answer for me. Is there any ownership or permissions combination that is more restrictive than the above? Does it really need to be world readable? You've asked a few different questions; the answer to the last one is 'no'. -- Sahil Tandon sa...@freebsd.org
Re: local.cf permissions
On Sun, 3 Apr 2011 13:30:44 -0700, Ori Bani orib...@gmail.com wrote: From what I can tell, it is common to have local.cf permissions/ownership as root:root 644 (rw-r--r--) correct But I have some database passwords (bayes, awl) in that file and would like NOT to have world read permissions on that file. put this passwords in user_prefs for that user that the deamond runs as and make it only readeable by this user for amavisd its chown vscan user_prefs chmod 0600 user_prefs in vscan homedir cd ~vscan cd .spamassassin put the user_prefs there sorry by my bad english, but its what i have done in long time to secure it
Re: local.cf permissions
On Sun, Apr 3, 2011 at 2:08 PM, Sahil Tandon sa...@freebsd.org wrote: On Sun, 2011-04-03 at 13:30:44 -0700, Ori Bani wrote: From what I can tell, it is common to have local.cf permissions/ownership as root:root 644 (rw-r--r--) But I have some database passwords (bayes, awl) in that file and would like NOT to have world read permissions on that file. I'm not entirely sure what process reads that file and what user that process runs as, so I hope that's an easy question you can answer for me. Is there any ownership or permissions combination that is more restrictive than the above? Does it really need to be world readable? You've asked a few different questions; the answer to the last one is 'no'. Can you elaborate? The systemwide local.cf (/etc/mail/spamassassin/local.cf) where my database passwords are located seems to need to be world readable according to docs I've read on the web (so that each user gets the default settings in that file I think). So how can I preserve that functionality without having global read permission on that file?
Re: Testing new server
On 04/03, Alex wrote:
How can I either use the existing system or emails stored on the
current system to test the new system before putting it into
production?
The best option may be to create a temporary DNS MX Record pointing to the
new server, and just send mail to it. If normal mail gets flagged as
spam, or mail with http://spamassassin.apache.org/gtube/ gets flagged
as non-spam, the test has failed.
Actually, you don't need an MX record. Just put the host name of the
server after the @ in the email address. Or username@[IP_address] (with
square brackets) might work.
You could try forwarding some of your emails from the old system, but you
won't be able to mimic them perfectly because you can't forge the sending
IP. But you could copy a bunch of them over and run spamassassin on them
after delivery, probably using formail.
Without formail, if your mailboxes are in Maildir format, you can check
a ham folder for false positives with:
for file in `find /home/darxus/Maildir/{cur,new} -type f` ; do spamc $file
output ; done
Then do grep 'X-Spam-Status: Yes' output to find false positives.
--
My free public whitelist + blacklist needs your input:
http://www.chaosreigns.com/iprep/
Re: local.cf permissions
On Sun, Apr 3, 2011 at 2:38 PM, Benny Pedersen m...@junc.org wrote: On Sun, 3 Apr 2011 13:30:44 -0700, Ori Bani orib...@gmail.com wrote: From what I can tell, it is common to have local.cf permissions/ownership as root:root 644 (rw-r--r--) correct But I have some database passwords (bayes, awl) in that file and would like NOT to have world read permissions on that file. put this passwords in user_prefs for that user that the deamond runs as and make it only readeable by this user for amavisd its chown vscan user_prefs chmod 0600 user_prefs in vscan homedir cd ~vscan cd .spamassassin put the user_prefs there Well I call spamc/spamd from courier maildrop. So my spamd startup options use the -u flag to run it as the user maildrop. That's only a system account and I'd rather not create user prefs for that user if possible (but will if I have to). I played with it and set /etc/mail/spamassassin/local.cf to: root:root 600 (rw---) And it seems to work fine in simple testing. So even though it's not readable by the maildrop user that spamd runs as, it still works. Why is that? Does spamd start as root and read system-wide local.cf before changing to the user indicated by the -u flag? If that's the case, wouldn't it do that no matter how you're using spamd? In what environments does the systemwide local.cf need to be world readable???
Re: local.cf permissions
On Sun, 3 Apr 2011 15:16:06 -0700, Ori Bani orib...@gmail.com wrote: I played with it and set /etc/mail/spamassassin/local.cf to: root:root 600 (rw---) updates will reset it to 644 And it seems to work fine in simple testing. spamd starts as root and drop privileges when local.cf is readed into mem So even though it's not readable by the maildrop user that spamd runs as, it still works. Why is that? Does spamd start as root and read system-wide local.cf before changing to the user indicated by the -u flag? if maildrop have a homedir, then its user_prefs is also readed, but i have not needed to use local.cf to have passwords still :)
Re: local.cf permissions
On Mon, 4 Apr 2011, Benny Pedersen wrote: On Sun, 3 Apr 2011 15:16:06 -0700, Ori Bani orib...@gmail.com wrote: I played with it and set /etc/mail/spamassassin/local.cf to: root:root 600 (rw---) updates will reset it to 644 ...so create /etc/mail/spamassassin/passwords.cf root:root 600 and put just the sensitive entries in it. On Sun, 3 Apr 2011, Ori Bani wrote: In what environments does the systemwide local.cf need to be world readable??? Ones where any user can run spamassassin (vs. spamc) and have it work fully. If you say only spamc is supported as an administrative rule, and you protect your sensitive data as above, you're probably good. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Ignorance is no excuse for a law. --- 10 days until Thomas Jefferson's 268th Birthday
Re: local.cf permissions
I played with it and set /etc/mail/spamassassin/local.cf to: root:root 600 (rw---) updates will reset it to 644 Really? Doesn't that depend on delivery method (yum, apt-get, etc)? Permissions get reset? But custom changes *inside* that file will be preserved, won't they? ...so create /etc/mail/spamassassin/passwords.cf root:root 600 and put just the sensitive entries in it. Ah! So any .cf file in /etc/mail/spamassassin will automatically be read upon startup (similar to Apache's conf.d directory)? That's very handy. In what environments does the systemwide local.cf need to be world readable??? Ones where any user can run spamassassin (vs. spamc) and have it work fully. Ah, thank you. If you say only spamc is supported as an administrative rule, and you protect your sensitive data as above, you're probably good. Thanks much John and Benny!
Problems with sorbs and this list Fwd: Re: What blacklists are you using at your MTA?
Figured I'd forward this along, since he can't post to the list due apparently to this list's use of sorbs. The IP address I got it from was 67.210.225.171. Interestingly, sorbs' website says it's not actively listed, but their DNS zone says otherwise. And their website conveys a general state of brokenness. And requires too damn much personal information to be able to do anything. (I did end up disabling sorbs and enabling psbl at my MTA.) And I don't know anything about this guy or this IP other than what was just emailed to me here. Other than it has a DNSWL rank of low, which could easily mean we know nothing bad about it, but just haven't had enough info to increase its rank. And it has no DNSWL abuse reports. - Forwarded message from Jonathan Nichols jnich...@pbp.net - Date: Sun, 3 Apr 2011 18:45:56 -0500 From: Jonathan Nichols jnich...@pbp.net To: dar...@chaosreigns.com Cc: users@spamassassin.apache.org Subject: Re: What blacklists are you using at your MTA? X-DNSWL: low pbp.net DNSWLId 23144 On Apr 2, 2011, at 8:24 PM, dar...@chaosreigns.com wrote: I'm curious what blacklists other people are currently using at their MTA, rejecting during delivery, before mail gets to spamassassin. For a while I've been using zen.spamhaus.org and dnsbl.sorbs.net. Based on recent stats ( http://ruleqa.spamassassin.org/?daterev=20110319 ) I think I'm dropping sorbs and adding psbl.surriel.com. At the MTA? None at the moment, and I have no idea if this will reach you since SORBS still has my entire netblock incorrectly listed as dynamic and they absolutely refuse to communicate about it - or address the issue. The irony. I cannot write to the Spamassassin list because Apache.org is using SORBS - which is broken and is incorrectly flagging clean IPs still. Thus limiting my ability to communicate with peers and help address the spam problem I have going on.. one that SORBS sure hasn't helped. The IPs that are spamming me? Listed clean in SORBS. :/ - End forwarded message - -- I love God. He's so deliciously evil. - Stewie Griffin, Family Guy 2x02 http://www.ChaosReigns.com
Re: Problems with sorbs and this list Fwd: Re: What blacklists are you using at your MTA?
If you go through the garbage required to register to get to the contents of this link, you'll see that this IP hits two listings, Escalated entries, and DUHL entries, both of which are colored green, which it says means Historical Listings (inactive). But it's still listed: $ host 171.225.210.67.dnsbl.sorbs.net 171.225.210.67.dnsbl.sorbs.net has address 127.0.0.10 - Forwarded message from Jonathan Nichols jnich...@pbp.net - users@spamassassin.apache.org: host mx1.eu.apache.org[192.87.106.230] said: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?67.210.225.171 (in reply to RCPT TO command) - End forwarded message - -- ...this thing we call 'failure' is not the falling down, but the staying down. - Mary Pickford http://www.ChaosReigns.com
Re: local.cf permissions
On Sun, 2011-04-03 at 14:38:49 -0700, Ori Bani wrote: On Sun, Apr 3, 2011 at 2:08 PM, Sahil Tandon sa...@freebsd.org wrote: On Sun, 2011-04-03 at 13:30:44 -0700, Ori Bani wrote: From what I can tell, it is common to have local.cf permissions/ownership as root:root 644 (rw-r--r--) But I have some database passwords (bayes, awl) in that file and would like NOT to have world read permissions on that file. I'm not entirely sure what process reads that file and what user that process runs as, so I hope that's an easy question you can answer for me. Is there any ownership or permissions combination that is more restrictive than the above? Does it really need to be world readable? You've asked a few different questions; the answer to the last one is 'no'. Can you elaborate? The systemwide local.cf (/etc/mail/spamassassin/local.cf) where my database passwords are located seems to need to be world readable according to docs I've read on the web (so that each user gets the default settings in that file I think). So how can I preserve that functionality without having global read permission on that file? My permissions for local.cf are: -rw-r- And I've had no problems for several years now. How do you reconcile that with what you've read 'on the web'? Different situations and needs will merit different solutions. Your question was general and received a general response. :) -- Sahil Tandon sa...@freebsd.org
Re: Testing new server
On 03/04/11 22:04, Alex wrote: Hi all, I've just installed a new server using fedora14 with spamassassin, amavisd, postfix, and dovecot. I've configured it the same to the best of my ability as an existing server currently in production that I would like to replace with this new system. This is a significant upgrade from the current system, so all software versions are different. How can I either use the existing system or emails stored on the current system to test the new system before putting it into production? I'd like to make sure that amavis and spamassassin are configured properly before switching the two systems and learning I've configured something wrong and avoid it rejecting mail, marking it incorrectly, or other possible configuration problems. Any ideas greatly appreciated. Thanks, Alex You can inject messages into postfix like so: sendmail -i recipient message.txt both ham and spam, and observe (/var/log/maillog) if they are processed as expected. That should test your Postfix/Amavisd/SpamAssassin/Dovecot chain. Amavisd provides sample spam messages if you don't have any.
