You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Robert - elists <li...@abbacomm.net> on 2008/06/02 21:20:54 UTC
google netblocks records etc
Since they seem to have zillions of outbound mx machines
I did this in response to some email latency issues.
dig google.com txt
google.com. 31 IN TXT "v=spf1
include:_netblocks.google.com ~all"
then i
dig _netblocks.google.com txt
_netblocks.google.com. 47 IN TXT "v=spf1 ip4:216.239.32.0/19
ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18
ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20
ip4:207.126.144.0/20 ?all"
Are most of you whitelisting these blocks ?
has anyone noticed if these are pretty static or do these TXT records change
frequently or otherwise?
- rh
Re: google netblocks records etc
Posted by D Hill <d....@yournetplus.com>.
On Tue, 3 Jun 2008 at 15:30 +0200, mouss@netoyen.net confabulated:
> D Hill wrote:
>> [snip]
>> In Postfix:
>>
>> reject_unknown_reverse_client_hostname
>> Reject the request when the client IP address has no address->name
>> mapping.
>>
>> reject_unknown_client_hostname
>> Reject the request when 1) the client IP address->name mapping fails,
>> 2) the name->address mapping fails, or 3) the name->address mapping
>> does not match the client IP address.
>>
>> reject_unknown_client_hostname would be what you are calling confirmed
>> reverse. If I were to use that, support would start getting phone calls and
>> customers would start getting upset.
>
> He is about check_client_access.
>
> recent postfix also have check_reverse_client_hostname_access which acts on
> PTR (unconfirmed rDNS), but is intended for blocking, not whitelisting.
Yes. Don't know where my head was...
Re: google netblocks records etc
Posted by mouss <mo...@netoyen.net>.
D Hill wrote:
> [snip]
> In Postfix:
>
> reject_unknown_reverse_client_hostname
> Reject the request when the client IP address has no address->name
> mapping.
>
> reject_unknown_client_hostname
> Reject the request when 1) the client IP address->name mapping fails,
> 2) the name->address mapping fails, or 3) the name->address mapping
> does not match the client IP address.
>
> reject_unknown_client_hostname would be what you are calling confirmed
> reverse. If I were to use that, support would start getting phone
> calls and customers would start getting upset.
He is about check_client_access.
recent postfix also have check_reverse_client_hostname_access which acts
on PTR (unconfirmed rDNS), but is intended for blocking, not whitelisting.
Re: google netblocks records etc
Posted by D Hill <d....@yournetplus.com>.
On Tue, 3 Jun 2008 at 16:15 +0300, hege@hege.li confabulated:
> On Tue, Jun 03, 2008 at 01:08:07PM +0000, D Hill wrote:
>> On Tue, 3 Jun 2008 at 15:42 +0300, hege@hege.li confabulated:
>>
>>> On Tue, Jun 03, 2008 at 02:02:29PM +0200, Benny Pedersen wrote:
>>>>
>>>>> http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS
>>>>
>>>> i know this fact, but OP question only based on reverse :/
>>>
>>> One should always assume "reverse" means _confirmed_ reverse. I don't know
>>> why anyone would assume otherwise by default. :) Especially if we are
>>> talking about serious software like postfix etc.
>>
>> In Postfix:
>>
>> reject_unknown_reverse_client_hostname
>> Reject the request when the client IP address has no address->name
>> mapping.
>>
>> reject_unknown_client_hostname
>> Reject the request when 1) the client IP address->name mapping fails,
>> 2) the name->address mapping fails, or 3) the name->address mapping
>> does not match the client IP address.
>>
>> reject_unknown_client_hostname would be what you are calling confirmed
>> reverse. If I were to use that, support would start getting phone calls
>> and customers would start getting upset.
>
> You are talking about rejecting clients with bad DNS. Not only it's
> guaranteed to reject legimate mail in both cases, but it's not even in scope
> of this thread. We are talking about identifying mail coming from google.
Sorry. Response retracted.
Re: google netblocks records etc
Posted by Henrik K <he...@hege.li>.
On Tue, Jun 03, 2008 at 01:08:07PM +0000, D Hill wrote:
> On Tue, 3 Jun 2008 at 15:42 +0300, hege@hege.li confabulated:
>
>> On Tue, Jun 03, 2008 at 02:02:29PM +0200, Benny Pedersen wrote:
>>>
>>>> http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS
>>>
>>> i know this fact, but OP question only based on reverse :/
>>
>> One should always assume "reverse" means _confirmed_ reverse. I don't know
>> why anyone would assume otherwise by default. :) Especially if we are
>> talking about serious software like postfix etc.
>
> In Postfix:
>
> reject_unknown_reverse_client_hostname
> Reject the request when the client IP address has no address->name
> mapping.
>
> reject_unknown_client_hostname
> Reject the request when 1) the client IP address->name mapping fails,
> 2) the name->address mapping fails, or 3) the name->address mapping
> does not match the client IP address.
>
> reject_unknown_client_hostname would be what you are calling confirmed
> reverse. If I were to use that, support would start getting phone calls
> and customers would start getting upset.
You are talking about rejecting clients with bad DNS. Not only it's
guaranteed to reject legimate mail in both cases, but it's not even in scope
of this thread. We are talking about identifying mail coming from google.
Re: google netblocks records etc
Posted by D Hill <d....@yournetplus.com>.
On Tue, 3 Jun 2008 at 15:42 +0300, hege@hege.li confabulated:
> On Tue, Jun 03, 2008 at 02:02:29PM +0200, Benny Pedersen wrote:
>>
>>> http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS
>>
>> i know this fact, but OP question only based on reverse :/
>
> One should always assume "reverse" means _confirmed_ reverse. I don't know
> why anyone would assume otherwise by default. :) Especially if we are
> talking about serious software like postfix etc.
In Postfix:
reject_unknown_reverse_client_hostname
Reject the request when the client IP address has no address->name
mapping.
reject_unknown_client_hostname
Reject the request when 1) the client IP address->name mapping fails,
2) the name->address mapping fails, or 3) the name->address mapping
does not match the client IP address.
reject_unknown_client_hostname would be what you are calling confirmed
reverse. If I were to use that, support would start getting phone calls
and customers would start getting upset.
Re: google netblocks records etc
Posted by Henrik K <he...@hege.li>.
On Tue, Jun 03, 2008 at 02:02:29PM +0200, Benny Pedersen wrote:
>
> > http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS
>
> i know this fact, but OP question only based on reverse :/
One should always assume "reverse" means _confirmed_ reverse. I don't know
why anyone would assume otherwise by default. :) Especially if we are
talking about serious software like postfix etc.
Re: google netblocks records etc
Posted by Benny Pedersen <me...@junc.org>.
On Tue, June 3, 2008 12:34, Henrik K wrote:
> Do you have access to google's DNS?
only use it from spf
> http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS
i know this fact, but OP question only based on reverse :/
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: google netblocks records etc
Posted by Henrik K <he...@hege.li>.
On Tue, Jun 03, 2008 at 11:56:41AM +0200, Benny Pedersen wrote:
>
> On Tue, June 3, 2008 08:32, Henrik K wrote:
>
> >> What I am talking about is not greylisting google based upon those addresses
> >> and sending right to SA for scoring
>
> try spf, and skip greylist based on pass, well still not good since spammers
> can olso use spf, but still alot better then below here
>
> > Why would you care about the IP addresses? Just whitelist by *.google.com.
>
> super let me change my reverse dns :-)
Dear Benny, I can't forgive your cluelessness, even if you are a dane.
Do you have access to google's DNS?
http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS
Re: google netblocks records etc
Posted by mouss <mo...@netoyen.net>.
Robert - elists wrote:
>> I think he meant whitelisting when the rDNS is verified (FcrDNS) by a
>> "double lookup". That's what a postfix check_client_access will do.
>>
>> [snip]
>>
>
> Mouss
>
> I think I wanted to whitelist inside my greylist the google IP netblocks
> space.
>
> They have a zillion outbound MX servers and some clients "appear" to be
> experiencing serious delays when we fine tune some other parameters.
>
> So therefore, whitelisting google IPs in the greylist data would allow the
> google email to go straight through to SA for scoring and other processing
>
I have
check_client_access
cidr:${config_directory}/maps/cidr/dnswl.org/postfix-dnswl-permit
where the file is synchronized using rsync.
This skips all client checks (including DNSBL lookups) for ranges listed
in dnswl.
Alternatively, you can lookup the spf ranges periodically, and update a
local whitelist.
That said, I only do selective greylisting (only greylist under certain
conditions).
PS. This thread should move to another forum as it's not really SA related.
RE: google netblocks records etc
Posted by Robert - elists <li...@abbacomm.net>.
>
> I think he meant whitelisting when the rDNS is verified (FcrDNS) by a
> "double lookup". That's what a postfix check_client_access will do.
>
> [snip]
Mouss
I think I wanted to whitelist inside my greylist the google IP netblocks
space.
They have a zillion outbound MX servers and some clients "appear" to be
experiencing serious delays when we fine tune some other parameters.
So therefore, whitelisting google IPs in the greylist data would allow the
google email to go straight through to SA for scoring and other processing
- rh
Re: google netblocks records etc
Posted by Leonardo Rodrigues Magalhães <le...@solutti.com.br>.
Benny Pedersen escreveu:
> whitelist_dnsname in policyd does it, i will test if postfix does the same,
> thanks for pointing it out :-)
>
>
policyd does whitelist_dnsname based on reverse passed by postfix.
policyd itself does NOT reverse lookups.
The good is that postfix only passes reverses do policy servers,
including policyd, if the reverse is OK in forward and reverse
configurations. if the ip->name is OK, but name->ip is not OK, than
policy server will receive 'unknown' as reverse name, even if the
ip->name do have some reverse.
that way, whitelist_dnsname feature from policyd can be used with no
more worries, because it will only match those 100% Ok reverse names.
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
Re: google netblocks records etc
Posted by Benny Pedersen <me...@junc.org>.
On Tue, June 3, 2008 12:38, mouss wrote:
> I think he meant whitelisting when the rDNS is verified (FcrDNS) by a
> "double lookup". That's what a postfix check_client_access will do.
whitelist_dnsname in policyd does it, i will test if postfix does the same,
thanks for pointing it out :-)
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: google netblocks records etc
Posted by mouss <mo...@netoyen.net>.
Benny Pedersen wrote:
> On Tue, June 3, 2008 08:32, Henrik K wrote:
>
>
>>> What I am talking about is not greylisting google based upon those addresses
>>> and sending right to SA for scoring
>>>
>
> try spf, and skip greylist based on pass, well still not good since spammers
> can olso use spf, but still alot better then below here
>
>
>> Why would you care about the IP addresses? Just whitelist by *.google.com.
>>
>
> super let me change my reverse dns :-)
>
I think he meant whitelisting when the rDNS is verified (FcrDNS) by a
"double lookup". That's what a postfix check_client_access will do.
[snip]
Re: google netblocks records etc
Posted by Benny Pedersen <me...@junc.org>.
On Tue, June 3, 2008 08:32, Henrik K wrote:
>> What I am talking about is not greylisting google based upon those addresses
>> and sending right to SA for scoring
try spf, and skip greylist based on pass, well still not good since spammers
can olso use spf, but still alot better then below here
> Why would you care about the IP addresses? Just whitelist by *.google.com.
super let me change my reverse dns :-)
> You shouldn't even greylist anything with *smtp* in the hostname:
super one more time let me include smtp in my reverse
> http://hege.li/howto/spam/etc/postfix/in/whitelist_client.pcre
crap :-)
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: google netblocks records etc
Posted by Henrik K <he...@hege.li>.
On Mon, Jun 02, 2008 at 01:23:33PM -0700, Robert - elists wrote:
> Ok
>
> Yellow then.
>
> What I am talking about is not greylisting google based upon those addresses
> and sending right to SA for scoring
Why would you care about the IP addresses? Just whitelist by *.google.com.
You shouldn't even greylist anything with *smtp* in the hostname:
http://hege.li/howto/spam/etc/postfix/in/whitelist_client.pcre
RE: google netblocks records etc
Posted by Robert - elists <li...@abbacomm.net>.
Ok
Yellow then.
What I am talking about is not greylisting google based upon those addresses
and sending right to SA for scoring
- rh
Re: google netblocks records etc
Posted by Marc Perkel <ma...@perkel.com>.
Robert - elists wrote:
> Since they seem to have zillions of outbound mx machines
>
> I did this in response to some email latency issues.
>
> dig google.com txt
>
> google.com. 31 IN TXT "v=spf1
> include:_netblocks.google.com ~all"
>
> then i
>
> dig _netblocks.google.com txt
>
> _netblocks.google.com. 47 IN TXT "v=spf1 ip4:216.239.32.0/19
> ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18
> ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20
> ip4:207.126.144.0/20 ?all"
>
> Are most of you whitelisting these blocks ?
>
> has anyone noticed if these are pretty static or do these TXT records change
> frequently or otherwise?
>
> - rh
>
>
What I do is what I call "yellow listing" which means don't blacklist or
whitelist. Google is a mixed source of spam and nonspam and the IP
address caries no information as to the spam status.
So what I do is I check the FCrDNS of the host that connect to my server
and if it ends in google.com then it's yellow.
Re: google netblocks records etc
Posted by Benny Pedersen <me...@junc.org>.
On Mon, June 2, 2008 21:20, Robert - elists wrote:
> Are most of you whitelisting these blocks ?
no whitelist here
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: google netblocks records etc
Posted by Leonardo Rodrigues Magalhães <le...@solutti.com.br>.
Robert - elists escreveu:
> Since they seem to have zillions of outbound mx machines
>
> Are most of you whitelisting these blocks ?
>
> has anyone noticed if these are pretty static or do these TXT records change
> frequently or otherwise?
>
the only whitelist i apply to gmail is whitelist their servers from
greylist measures. All hosts which match:
'__-out-____.google.com'
wont be greylisted. No more whitelists and no more privileges than
that. If the message cames in, it will be SPAM/virus scanned just like
all the others.
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
Re: google netblocks records etc
Posted by mouss <mo...@netoyen.net>.
Robert - elists wrote:
> Since they seem to have zillions of outbound mx machines
>
> I did this in response to some email latency issues.
>
> dig google.com txt
>
> google.com. 31 IN TXT "v=spf1
> include:_netblocks.google.com ~all"
>
> then i
>
> dig _netblocks.google.com txt
>
> _netblocks.google.com. 47 IN TXT "v=spf1 ip4:216.239.32.0/19
> ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18
> ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20
> ip4:207.126.144.0/20 ?all"
>
> Are most of you whitelisting these blocks ?
>
You can use dnswl.
> has anyone noticed if these are pretty static or do these TXT records change
> frequently or otherwise?
>
> - rh
>
>