On Fri, Jun 26, 2009 at 5:17 PM, mouss<mo...@ml.netoyen.net> wrote: > so you would block mail from me?
Yes, in fact, the local "cache" mail server would refuse mail from everyone but the servers mentioned in the external service's SPF record hence creating sort of an unprotected, IP-based "tunnel" between the external service and the local server. The only MX for the serviced domains is that of the external service, so nobody but the external service's SMTP server should be looking for the local server's SMTP port; the local server only receives a copy of the received emails from the external service after spam filtering. The reason for the local service's existence is to improve the access speed to the received emails, and to function as an outbound SMTP for the LAN so that emails with large attachments are sent "immediately" from the users' point of view (even though large attachments can take several minutes to send over 2.8Mb internet connection). The local server's SMTP is open for "mynetworks" (the LAN), and also available via port 587 with SASL AUTH/TLS so that the users may use it for outbound mail. The serviced domains' SPF records include both the external service's SPF record (via include:) and the IP of the local server (via IP4:). I'm not totally sold on SPF for it's spam-preventing capability, but it is handy in automating the check_client_access CIDR map as has been discussed in this thread. And its use possibly discourages spammers from using the business domains by making it more likely for the emails with forged headers to end up trapped by the spam filters. I've tested this now intially, and it seems to be working well. It's a bit of a kludge, but gives best of both worlds to the users at a very low cost: stability and features of a managed external service, and speed of a local service. > all that said, if you whitelist IPs or blocks, please submit them to DNSWL. Thanks for that tip! I wasn't aware of DNSWL, but will look into it. Ville
