Re: blacklist.mailrelay.att.net
Le 12/12/2010 19:23, Giampaolo Tomassoni a écrit : I just got blocked by the ATT's blacklist (in contacting ab...@att.com, besides...), but I'm pretty sure my MX is not an open relay or other kind of nifty thing. $ host tomassoni.biz tomassoni.biz has address 62.149.201.242 tomassoni.biz has address 62.149.220.102 $ host 62.149.201.242 242.201.149.62.in-addr.arpa domain name pointer host242-201-149-62.serverdedicati.aruba.it. $ host 62.149.220.102 102.220.149.62.in-addr.arpa domain name pointer host102-220-149-62.serverdedicati.aruba.it. So both IPs use generic hostnames, which are a sign of half configured servers. Unfortunately the RDNS is not under my control. Which is a fact I share with a lot of people worldwide... think as the receiving side. when I see spam out of joe.spam.example, I blocklist spam.example (and possibly every IP and domain related to them). If I see spam coming from host1-2-364.serverdedicati.aruba.it, what will I blacklist? On 13.12.10 11:14, Giampaolo Tomassoni wrote: I personally (and many serious blocklists) would block the single spamming address. I would not call what's att doing a spam blocking. I'd rather call that policy blocking which means you need to have DNS records that clearly say the IPs are not dynamically assigned. The policy we don't accept (unauthenticated) mail from dynamic hosts is quite common and logical. You may easily see that Aruba.it is a co-location provider, so you may easily understand that different hosts from the same address bunch are probably handled by different organizations, with different means and purposes. To me, it is counter-productive to block the whole bunch. ask aruba.it to configure reverse records properly. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
Re: SPF_PASS doesn't trigered
On 15.12.10 10:59, Nikolay Shopik wrote: I have domain hosted at google apps, and my domain have recomended by google txt record v=spf1 include:_spf.google.com ~all. So far when I receive mail from this domain spamassassin doesn't trigger rule SPF_PASS nor SPF_SOFTFAIL, is this normal? do you have SPF plugin loaded? do you have Mail-SPF perl module installed? do you have internal_networks properly configured? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: SPF_PASS doesn't trigered
On 15/12/10 12:04, Matus UHLAR - fantomas wrote: On 15.12.10 10:59, Nikolay Shopik wrote: I have domain hosted at google apps, and my domain have recomended by google txt record v=spf1 include:_spf.google.com ~all. So far when I receive mail from this domain spamassassin doesn't trigger rule SPF_PASS nor SPF_SOFTFAIL, is this normal? do you have SPF plugin loaded? do you have Mail-SPF perl module installed? do you have internal_networks properly configured? SPF plugin working just fine for other domains. To make it more clear, i've running SA at my domain and receiving mail from domain which is hosted at google apps (and have TXT record) so internal_networks has nothing to do with this.
Re: DNSBL for email addresses?
On 12/14/2010 8:31 PM, Philip Prindeville wrote: On 12/14/10 3:35 PM, Cedric Knight wrote: On 14/12/10 14:28, Marc Perkel wrote: Are there any DNSBLs out there based on email addresses? Since you can't use an @ in a DNS lookup Actually, you can use '@' in a lookup. You just can't use it in a hostname. Or you could convert the '@' to a '.' as is the format still used in SOA records. Not just SOA records, but the MB records were supposed to use this as well. They just never caught on. So how does this work for an address like first.l...@example.com? This would be converted to first.last.example.com, which is ambiguous and likely decoded to fi...@last.example.com. -- Bowie
Re: SPF_PASS doesn't trigered
On 15.12.10 10:59, Nikolay Shopik wrote: I have domain hosted at google apps, and my domain have recomended by google txt record v=spf1 include:_spf.google.com ~all. So far when I receive mail from this domain spamassassin doesn't trigger rule SPF_PASS nor SPF_SOFTFAIL, is this normal? On 15/12/10 12:04, Matus UHLAR - fantomas wrote: do you have SPF plugin loaded? do you have Mail-SPF perl module installed? do you have internal_networks properly configured? On 15.12.10 12:31, Nikolay Shopik wrote: SPF plugin working just fine for other domains. To make it more clear, i've running SA at my domain and receiving mail from domain which is hosted at google apps (and have TXT record) so internal_networks has nothing to do with this. oh yes, it has. The SPF check must be done on your network border, so properly set internal_networks is a must. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. -- Daffy Duck Porky Pig
Additional sa-update channels
Sorry all, Been away from the list for quite some time. Just updated SA from 3.2.5 to 3.3.1. Have been trying to find a list of sa-update channels that are still relevant but not with much success. Does anyone know is such a list exists, or if you know of which additional channels can still be used. I know a lot of them have been merged into SA and some are outdated and recommended not to be used. Thanks Andy
Re: Additional sa-update channels
On 12/15/2010 11:57 AM, Andy Jezierski wrote: Sorry all, Been away from the list for quite some time. Just updated SA from 3.2.5 to 3.3.1. Have been trying to find a list of sa-update channels that are still relevant but not with much success. Does anyone know is such a list exists, or if you know of which additional channels can still be used. I know a lot of them have been merged into SA and some are outdated and recommended not to be used. All of the good SARE rules have been merged into SA. All of the SARE update channels should no longer be used (as the rules are no longer being updated). The best additional channel to use at the moment is the Sought ruleset. http://wiki.apache.org/spamassassin/SoughtRules -- Bowie
Re: SPF_PASS doesn't trigered
my mx have public ip and not behind nat, should i add public ip of my mx into internal_networks? Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 15.12.10 10:59, Nikolay Shopik wrote: I have domain hosted at google apps, and my domain have recomended by google txt record v=spf1 include:_spf.google.com ~all. So far when I receive mail from this domain spamassassin doesn't trigger rule SPF_PASS nor SPF_SOFTFAIL, is this normal? On 15/12/10 12:04, Matus UHLAR - fantomas wrote: do you have SPF plugin loaded? do you have Mail-SPF perl module installed? do you have internal_networks properly configured? On 15.12.10 12:31, Nikolay Shopik wrote: SPF plugin working just fine for other domains. To make it more clear, i've running SA at my domain and receiving mail from domain which is hosted at google apps (and have TXT record) so internal_networks has nothing to do with this. oh yes, it has. The SPF check must be done on your network border, so properly set internal_networks is a must. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. -- Daffy Duck Porky Pig
Re: Comment - GFI/SORBS
This is a long and somewhat complex story. I've been running my own mail for 15+ years or so, always on a fixed IP. A few years ago business picked up so I got some additional IP's from my supplier (BT); it turned out that they were decommissioned DUL's renewed as statics. Initially we jumped the hoops (both BT I) and after several fraught weeks the issue was resolved. Now we hit November 27th this year, suddenly I'm in SORBS again. Nothing changed this end, same IP, same RIPE entry, same everything... apart from SORBS, who, apparently, redid their db at the end of November. Happily I am now clean and clear. How did I really end up there? I've no real idea, I suspect the reload. I really do appreciate the work RBL's do, mostly; it's a thankless task and if the same wit were applied adversely a lot of money could be made. That they are moral and work as they do makes the life of all legit server admins much easier until they get too rabid. For those of you that supply reliable rbl's, please accept my profound thanks. Some maybe could do better, perhaps those should be carefully judged before inclusion into sa, or perhaps made an optional? All that said, SA isn't the direct problem. Admins blocking purely on, for example, SORBS, should maybe rethink their strategy and adjust scoring on rules within SA. All of the above is my opinion only; I don't think SORBS do a bad job, I just think they could do it better, and maybe accept that we all get it wrong sometimes... Just my 2.5p worth :-D Kind regards Nigel On Tue, 14 Dec 2010 22:41:40 -0500, Jason Bertoch ja...@i6ix.com wrote: On 12/14/2010 8:06 PM, Bart Schaefer wrote: http://blog.wordtothewise.com/2010/12/gfi-sorbs-considered-harmful-part-5/ I've seen the headaches of getting off SORBS, but how did you really end up there? While I agree that SORBS is not reliable enough for use at the MTA level, I've not seen one complaint from my customers over using SORBS in SA. Isn't the beauty of SA the fact that you can score gray areas and not be stuck with black or white? In case it's a mystery, SA scores are automatically generated based on results from the corpus. If those results weren't productive, the rules would either be disabled or their scores adjusted even lower. However, if the corpus isn't representative, the generated scores are in error, and that means we need more trusted submitters. Or maybe your traffic is relatively unique and you should already be generating your own scores? Ultimately, this seems to be more of a witch hunt against SORBS than a SA issue. Although I'm not opposed to a SORBS witch hunt, I don't think it belongs here. /$.02
Re: SPF_PASS doesn't trigered
On ons 15 dec 2010 18:08:20 CET, Nikolay Shopik wrote my mx have public ip and not behind nat, should i add public ip of my mx into internal_networks? no, just trusted (you trust your own server, and forwarding ips) internal is more if you use servers in rfc1918 ip ranges other then that check envelope sender header is correct in spammassin -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Comment - GFI/SORBS
On Wed, 15 Dec 2010 07:04:18 +, corpus.defero corpus.def...@idnet.com wrote: Ultimately, this seems to be more of a witch hunt against SORBS than a SA issue. Although I'm not opposed to a SORBS witch hunt, I don't think it belongs here. Indeed, and it's Lynford and his money grabbing cronies mostly behind it - hence it lacks sophistication. I guess we all have our opinions based on our experiences. Personally, I've had no issue with zen, though cbl does seem sometimes to have an issue with back-scatter. That said, proper spf should help stop back-scatter. Kind regards Nigel
Re: Additional sa-update channels
On 15/12/2010 1:32 PM, Bowie Bailey wrote: On 12/15/2010 11:57 AM, Andy Jezierski wrote: Sorry all, Been away from the list for quite some time. Just updated SA from 3.2.5 to 3.3.1. Have been trying to find a list of sa-update channels that are still relevant but not with much success. Does anyone know is such a list exists, or if you know of which additional channels can still be used. I know a lot of them have been merged into SA and some are outdated and recommended not to be used. All of the good SARE rules have been merged into SA. All of the SARE update channels should no longer be used (as the rules are no longer being updated). The best additional channel to use at the moment is the Sought ruleset. http://wiki.apache.org/spamassassin/SoughtRules Have to disagree on the Sought rules. I've seen them give quite a few false positives (mostly on e-mail notifications from social networks Facebook and Twitter), and hit on hardly any spam at all. Your best best is to use the khop rules, along with one SARE set still being updated by Daryl. Below are the channels I recommend: updates.spamassassin.org khop-bl.sa.khopesh.com khop-blessed.sa.khopesh.com khop-dynamic.sa.khopesh.com khop-general.sa.khopesh.com khop-sc-neighbors.sa.khopesh.com 90_2tld.cf.sare.sa-update.dostech.net Regards, Lawrence
Re: SPF_PASS doesn't trigered
On 15.12.2010 20:33, Benny Pedersen wrote: On ons 15 dec 2010 18:08:20 CET, Nikolay Shopik wrote my mx have public ip and not behind nat, should i add public ip of my mx into internal_networks? no, just trusted (you trust your own server, and forwarding ips) internal is more if you use servers in rfc1918 ip ranges other then that check envelope sender header is correct in spammassin I did play more with gmail as example, and notice. If I send email from web interface SPF always matched and OK. If I'm using MUA to send mail via SMTP it never fail or pass SPF rule. Probably new Received: header is related, any ideas?
Re: SPF_PASS doesn't trigered
On ons 15 dec 2010 19:20:28 CET, Nikolay Shopik wrote I did play more with gmail as example, and notice. If I send email from web interface SPF always matched and OK. If I'm using MUA to send mail via SMTP it never fail or pass SPF rule. Probably new Received: header is related, any ideas? sendmail vs smtp ? -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: SPF_PASS doesn't trigered
On 15.12.2010 21:28, Benny Pedersen wrote: On ons 15 dec 2010 19:20:28 CET, Nikolay Shopik wrote I did play more with gmail as example, and notice. If I send email from web interface SPF always matched and OK. If I'm using MUA to send mail via SMTP it never fail or pass SPF rule. Probably new Received: header is related, any ideas? sendmail vs smtp ? I probably mean sent word, I don't use sendmail. My MUA is Thunderbird.
Re: SPF_PASS doesn't trigered
On ons 15 dec 2010 19:34:12 CET, Nikolay Shopik wrote I probably mean sent word, I don't use sendmail. My MUA is Thunderbird. thunderbird use smtp, web apps does not use smtp ? that would explain why its working or not logs please -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Additional sa-update channels
On 12/15/2010 1:00 PM, Lawrence @ Rogers wrote: On 15/12/2010 1:32 PM, Bowie Bailey wrote: On 12/15/2010 11:57 AM, Andy Jezierski wrote: Sorry all, Been away from the list for quite some time. Just updated SA from 3.2.5 to 3.3.1. Have been trying to find a list of sa-update channels that are still relevant but not with much success. Does anyone know is such a list exists, or if you know of which additional channels can still be used. I know a lot of them have been merged into SA and some are outdated and recommended not to be used. All of the good SARE rules have been merged into SA. All of the SARE update channels should no longer be used (as the rules are no longer being updated). The best additional channel to use at the moment is the Sought ruleset. http://wiki.apache.org/spamassassin/SoughtRules Have to disagree on the Sought rules. I've seen them give quite a few false positives (mostly on e-mail notifications from social networks Facebook and Twitter), and hit on hardly any spam at all. Your best best is to use the khop rules, along with one SARE set still being updated by Daryl. Below are the channels I recommend: updates.spamassassin.org khop-bl.sa.khopesh.com khop-blessed.sa.khopesh.com khop-dynamic.sa.khopesh.com khop-general.sa.khopesh.com khop-sc-neighbors.sa.khopesh.com 90_2tld.cf.sare.sa-update.dostech.net The khop rules are good. I thought the 2tld stuff had been pulled into SA as 20_aux_tlds.cf? -- Bowie
Re: SPF_PASS doesn't trigered
On ons 15 dec 2010 20:05:46 CET, Nikolay Shopik wrote Both using smtp when delivering mail to my server, difference is only in headers. no logs ? have you configured envelope sender in spamassassin ? or better yet readed perldoc Mail::SpamAssassin::Conf perldoc Mail::SpamAssassin::Plugin::SPF have you installed Mail::SPF::Query or Mail::SPF ? first one is depricated -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Additional sa-update channels
On 15/12/2010 3:51 PM, Bowie Bailey wrote: The khop rules are good. I thought the 2tld stuff had been pulled into SA as 20_aux_tlds.cf? It has, but the Daryl edited one has some additional stuff (I think) that isn't in there. There is conditional code that enables certain rules in the file depending on what version of SA you are running.
Re: SPF_PASS doesn't trigered
Problem was in spf: relayed through one or more trusted relays, cannot use header-based Envelope-From always_trust_envelope_sender 1 is helps in my case, both of my trusted relays are 127.0.0.1. On 15.12.10 22:29, Benny Pedersen wrote: On ons 15 dec 2010 20:05:46 CET, Nikolay Shopik wrote Both using smtp when delivering mail to my server, difference is only in headers. no logs ? have you configured envelope sender in spamassassin ? or better yet readed perldoc Mail::SpamAssassin::Conf perldoc Mail::SpamAssassin::Plugin::SPF have you installed Mail::SPF::Query or Mail::SPF ? first one is depricated
Re: SPF_PASS doesn't trigered
On ons 15 dec 2010 22:58:29 CET, Nikolay Shopik wrote Problem was in spf: relayed through one or more trusted relays, cannot use header-based Envelope-From always_trust_envelope_sender 1 is helps in my case, both of my trusted relays are 127.0.0.1. so more then one header is needed in your case ? -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: SPF_PASS doesn't trigered
On 16/12/10 01:04, Benny Pedersen wrote: so more then one header is needed in your case ? Well SA only see first header, second header added after mail re-inserted into queue after SA check. What I don't understand is why it was working for some hosts before, because there always at least one trusted_hosts which prevent SA to do SPF checks.
