Andrew J. Schorr:
> Wietse Venema wrote:
> > A possible option is to periodically grab the SPF records of Amazon,
> > Google, and the like, and to whitelist those IP addresses permanently.
>
> I had been hoping that the whitelisting would obviate the need to do
> something like this. Perhaps with the extra whitelists that I added,
> this may not be necessary. Is there a simple tool that translates the
> SPF record into a set of IP addresses? For example:
>
> bash-4.2$ host -t txt amazon.com
> amazon.com descriptive text "v=spf1 include:spf1.amazon.com
> include:spf2.amazon.com include:amazonses.com -all"
> amazon.com descriptive text "spf2.0/pra include:spf1.amazon.com
> include:spf2.amazon.com include:amazonses.com -all"
When you follow the include: directives you get lists of net/mask
forms that are easy to convert to postscreen.
$ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{
s/^ip.:\(.*\)/\1 permit/
p
}' | sort -u
I thought there would be a nice script that converts SPF net/mask
lists to postscreen access lists but I could not quickly find one.
> > I mention Google here because they, too, would not retry from the
> > same client IP address when I was using deep protocol tests.
>
> I was aware of that, so I checked that some typical google addresses were in
> list.dnswl.org before enabling the deep protocol tests. I didn't realize that
> Amazon also had this behavior, although, to be fair, the first 3 Amazon
> attempts were from the same IP address. It was just that the timeout problem
> caused those 3 attempts to fail, and subsequent attempts used many different
> IP
> addresses.
>
> > A more robust fix may be to consider the deep protocol tests as
> > "completed" when receiving "RSET" after "RCPT TO" and the session
> > passes all tests up to that point. Then, "RSET" kind-of becomes
> > like "QUIT", except perhaps that it does not hang up.
>
> I'm certainly not qualified to say whether this is would be wise, but it
> does seem like it would help with this particular problem. I guess it could
> be an optional behavior if you're not sure that this is smart in all cases.
That would be an idea. It seems unlikely that the client will run
afoul after getting this far into the SMTP conversation, but having
a switch for this would allow sites to choose.
Wietse
