Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-13 23:57 UTC

Message

Re: [milter-greylist] dealing with mail relay "pools"?

2019-04-25 by Christian Pélissier

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.