Henrik K wrote:
On Fri, Nov 07, 2008 at 04:20:17PM +0200, Henrik K wrote:
On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote:
I'm not sure I like the ideas of whitelisting based on IP-addresses,
it's too inflexible. Why would you not use hostnames?
Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust
would go from hostname to hostname, so it's ok. :) Too little time to think.
IMO the right option is wildcards. You might as well ask then, why can't the
sender part be regexed for convienence..
One thing I still have to add. IPs are a pretty foolproof way to whitelist.
sure, IPs don't suffer dns temp failures, but when I intend to trust
*.gandi.net, I really want to trust *.gandi.net, not resolve that one
day, then have gandi add new relays that I don't trust, or even worst,
having the IP assigned to another organization.
and if you mean forged PTRs, then any software that trusts the PTR
without actually resolving it back to the IP is bogus. Those of us
running "real" MTAs don't have to suffer from such descrepancies.
of course, it is theortically possible to forge the name and attack DNS
so that it "fully" resolves, but in that case, a lot of other stuff
would break anyway (for good or for bad, we rely on dns too much).
With hostnames there is a bigger change of failure (by just using a domain
instead of exact hostname, letting f.e. dialup users from the domain forge
the path).
not sure I understand. people can't easily forge their rdns (in the
sense: FcrDNS. PTR alone is useless), and if they can, then they can do
other dns attacks making all dns based checks useless.
if you mean forging Received headers, well, that's not a problem as long
as the relay path is correctly parsed (don't trust infos beyond last
trusted received header).
