> > On 23.02.10 16:17, Bowie Bailey wrote: > >> SPF enforcement at the MTA is useless for the reasons you specified. > >> The only exception is if you have a strict SPF policy for your own > >> domain, you can use it to reject spam pretending to be from your users.
> Matus UHLAR - fantomas wrote: > > And what is this, if not enforcing SPF at MTA level? On 24.02.10 09:03, Bowie Bailey wrote: > This is selective enforcement of a domain (or list of domains) that are > known to have working SPF records. so, it's enabling/disabling of SPF usage for some domains. > > Also, this can be solved at MTA level without SPF enforcement. Afaik some > > servers are already rejecting mail from "their users" without proper > > authentification. > True, but then you need to keep track of which mail servers are allowed > to send mail for each domain. Which, coincidentally, is exactly what > SPF does. that's why I'd keep it on SPF, probably with listing of domains that should/shoult not be checked. It's much easier to do it with SPF than maintaining list of domains/servers. And you can even tell which domains (or their users) have broken setup and optionally notify them. For some domains/senders (e.g. freemails), we could argument that it's the freemail provider who wishes it this way and the sender is breaking the domain policy... > (This is assuming a more complex configuration than just rejecting > everything that does not originate locally.) otoh, it does much more for you. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
