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" There must be a simple program using libspf2 to do this, but I don't know what it is. I was hoping that the bundled spfquery program might do this, but the help message does not seem to indicate that it has this capability. If somebody knows the relevant tool, I would appreciate a pointer. > 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. Thanks for giving this some thought. Regards, Andy
