Le jeudi 25 avril 2019 � 08:12 -0400, 'Andrew J. Schorr' aschorr@... [milter-greylist] a �crit : > > On Thu, Apr 25, 2019 at 09:24:27AM +0200, Christian P�lissier > Christian.Pelissier@... [milter-greylist] wrote: > > For example gmail has four MX CIDR:74.125.0.0/16 > > and one in CIDR:108.177.0.0/17 > > > > # dig +short MX gmail.com > > 20 alt2.gmail-smtp-in.l.google.com. > > 30 alt3.gmail-smtp-in.l.google.com. > > 40 alt4.gmail-smtp-in.l.google.com. > > 10 alt1.gmail-smtp-in.l.google.com. > > 5 gmail-smtp-in.l.google.com. > > # dig +short alt1.gmail-smtp-in.l.google.com. > > 74.125.205.26 > > # dig +short alt2.gmail-smtp-in.l.google.com. > > 74.125.68.26 > > # dig +short alt3.gmail-smtp-in.l.google.com. > > 108.177.125.26 > > # dig +short alt4.gmail-smtp-in.l.google.com. > > 74.125.195.26 > > # dig +short gmail-smtp-in.l.google.com. > > 74.125.206.27 > > But if you look at the SPF records for gmail.com, which I think are > more > relevant than the MX records for this purpose, you see more subnets: > > dig +short -t txt gmail.com > "v=spf1 redirect=_spf.google.com" > > This expands to: > > ip4:35.190.247.0/24 > ip4:64.233.160.0/19 > ip4:66.102.0.0/20 > ip4:66.249.80.0/20 > ip4:72.14.192.0/18 > ip4:74.125.0.0/16 > ip4:108.177.8.0/21 > ip4:173.194.0.0/16 > ip4:209.85.128.0/17 > ip4:216.58.192.0/19 > ip4:216.239.32.0/19 > ip6:2001:4860:4000::/36 > ip6:2404:6800:4000::/36 > ip6:2607:f8b0:4000::/36 > ip6:2800:3f0:4000::/36 > ip6:2a00:1450:4000::/36 > ip6:2c0f:fb50:4000::/36 > ip4:172.217.0.0/19 > ip4:172.217.32.0/20 > ip4:172.217.128.0/19 > ip4:172.217.160.0/20 > ip4:172.217.192.0/19 > ip4:108.177.96.0/19 > ip4:35.191.0.0/16 > ip4:130.211.0.0/22 > > Regards, > Andy Sorry gmail.com and nasa.gov are not good examples because MX receive mail and SPF listed TXT record send mail. However if you look at all the SPF ipv4, /16 solve the problem if the pool sending again is in the same CIDR class. With SPF sender you can also use different delay to have a retry accepted quickly (it's not a solution to the pool problem) and if the sender retry period is short. ... racl greylist spf fail delay 45m racl greylist spf none delay 15m racl greylist spf pass delay 1m ... > > -- Christian P�lissier \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409 \ue201 34419
Message
Re: [milter-greylist] dealing with mail relay "pools"?
2019-04-25 by Christian Pélissier
Attachments
- No local attachments were found for this message.